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

[Christoph Lameter]

On Tue, 4 May 2004, Henrik Nordstrom wrote:

> On Mon, 3 May 2004, Christoph Lameter wrote:
>
> > > 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).
> >
> > Why is it then possible to do read() followed by write() without holding
> > the oplock? The file could be truncated after read() is complete.
>
> 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.