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

[Andrew Bartlett]

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 pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- 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 : http://lists.samba.org/archive/samba-technical/attachments/20040504/ba080fd7/attachment.bin