Optimization with sendfile

[Shlomi Yaakobovich]

Hi,

We have been doing some performance tests (streaming read/write), and I've noticed that whenever we use sendfile (in reply.c/send_file_readX), there is a call to SMB_VFS_FSTAT before the actual sendfile call. If I understand it correctly, then this is to figure out what size of data we're going to handle, and if the file has enough data to send (so we can build an appropriate header).

First of all, I see a race condition here, if someone is writing to the file, or worse, truncating it - then the sendfile would fail, although we already sent the header. I wonder if locking the file is a valid solution here ?  It will require a few system calls, which might render the use of sendfile useless.

Second, if we are taking the risk that the file is not being truncated during this call, why call fstat repeatedly ?  I can think of an optimization that before the first call to sendfile stats the file, and then, if we have an oplock on the file, not bother with the further stat calls. Same principal as with the auto strict locking. One issue that needs to be taken care of is resetting this size/flag whenever doing truncate, and maybe even on writes. This could give us a performance boost, from our initial tests up to 10%. The question is, is this use of oplocks appropriate here ?

Comments ?

Shlomi