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

Andrew Bartlett abartlet at
Tue May 4 00:21:30 GMT 2004

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).

So, this is still a bug, as what we should do here (I think, but others
more involved in this code should comment) is obtain our own oplock, for
the purpose of calling sendfile.

Andrew Bartlett

Andrew Bartlett                                 abartlet at
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list