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

[Henrik Nordstrom]

On Tue, 4 May 2004, Christoph Lameter wrote:

> > Because then the smb header is created based on the results of the read()
> > making it reflect what the write will send and there is no problem dealing
> > with the case that the file was truncated under our feets.
> 
> As I said the file could be truncated after the read is complete or while
> it is in progress. This is still a truncation under you feet.

If the file is not truncated under yor feets there is no problem. The 
problem discussed is only visible if the file is truncated while Samba is 
reading from it.

When using read the truncation is immediately detected by read() and a
correct SMB header can still be sent indicating the actual size of the
reply.  When using read the sequence of things is something like

  0. Read request from client
  1. read data from file
  2. make SMB header indicating the amount of data to be returned
  3. Send header and data to client

But in case of sendfile the order is slighly but importanly different, and 
looks something like:

  0. Read request from client
  1. Make SMB header indicating amount of data to be returned based on our 
current view of the file.
  3. Send SMB header to to client
  4. sendfile() the file data to client

As you can see above in case of sendfile the header has already been sent,
and unless special action is taken the SMB message will be malformed as it
is not possible to correct the already sent message header if sendfile
should detect that the file has been truncated under our feets.  It has
been proposed it may be ok in this case to fill in the missing data with
zeroes but as of yet Samba has not dared to do so and is why it is using
read() if there is no oplock, allowing it to send a correct response even
if the file is truncated under its feets.

Regards
Henrik