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

[Christoph Lameter]

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:

f.e. reply.c

int send_file_readX(connection_struct *conn, char *inbuf,char *outbuf,int length,
    files_struct *fsp, SMB_OFF_T startpos, size_t smb_maxcnt)
{
  ssize_t nread = -1;
  char *data = smb_buf(outbuf);

#if defined(WITH_SENDFILE)
  /*
   * We can only use sendfile on a non-chained packet and on a file
   * that is exclusively oplocked.
   */

  if ((CVAL(inbuf,smb_vwv0) == 0xFF) && EXCLUSIVE_OPLOCK_TYPE(fsp->oplock_type) &&
      lp_use_sendfile(SNUM(conn)) && (lp_write_cache_size(SNUM(conn)) == 0) ) {
    SMB_STRUCT_STAT sbuf;
    DATA_BLOB header;

...

Samba checks the normal locks before calling send_file_readX. Neither the
sendfile patch nor the regular read/write code path does any lock
processing.

So what is the purpose of the OPLOCK check there? Why is it not possible
to use sendfile without an OPLOCK?

I removed the check for the OPLOCK and now file accesses are faster.....