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

Christoph Lameter christoph at
Tue May 4 00:58:41 GMT 2004

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.

More information about the samba-technical mailing list