Removing OPLOCK check in sendfile processing (source/smbd/reply.c) increases speed

[Christoph Lameter]

On Tue, 4 May 2004, Andrew Bartlett wrote:

> On Tue, 2004-05-04 at 10:10, Christoph Lameter wrote:
> > Sendfile is much more effective on my system here than regular I/O.
> > However, in many situations samba does not use sendfile but uses regular
> > read() and write() instead reducing the throughput.
> >
> > I found that this is due to Windows not obtaining an OPLOCK in certain
> > circumstances (f.e. WinXP does not obtain oplock from CMD.EXE but gets
> > oplock when dragging file in explorer). Samba checks for an OPLOCK and
> > does not use sendfile if no OPLOCK has been obtained:
>
> The reason for the oplock check is that the way sendfile operates, we
> fill in the smb header, before we read the file.  Therefore, we must
> 'know' that the file is not going to change underneath us (in
> particular, will not be shorter).

Why is it then possible to do read() followed by write() without holding
the oplock? The file could be truncated after read() is complete.