Is kernel oplocks = yes a good default?

[J. Bruce Fields]

On Thu, Apr 12, 2012 at 06:45:11PM +0200, Christian Ambach wrote:
> On 04/11/2012 08:44 PM, J. Bruce Fields wrote:
> 
> >That said, ideally we'd have kernel support for level 2 oplocks and then
> >people wouldn't have to make this consistency/performance choice.
> >
> >(What's stopping that?  There's the downgrade problem reported here:
> >
> >	https://lists.samba.org/archive/samba-technical/2012-March/082376.html
> >
> >which I have on my todo list.  Is there anything else you need from the
> >kernel?)
> 
> My assumption is that the main user of leases in the kernel will be
> the NFSv4 server to handle delegations, so I tried to look up what
> NFSv4 would expect from them.
> The NFSv4.x RFCs do not have much detail of potential sources for
> lease breaks, here is what I was able to find:
> 
> >   The following events necessitate recall of an open delegation:
> >
> >   o  Potentially conflicting OPEN request (or READ/WRITE done with
> >      "special" stateid)
> >
> >   o  SETATTR issued by another client
> >
> >   o  REMOVE request for the file
> >
> >   o  RENAME request for the file as either source or target of the
> >      RENAME

Also, LINK.  (If you add a new hardlink pointing to the file, that
breaks any read delegation on it.) 

Basically, opens plus anything that would change the data, metadata, or
set of names pointing to a file should break a read delegation on that
file.

> 
> I think those pretty much correlate with what would be reasons for
> revocation on Windows.

I ask this same question before and got more or less the opposite
answer:

	http://www.spinics.net/lists/linux-nfs/msg24336.html

Based on that I've implemented a separate lock type for NFSv4
delegations which I'm using in kernel, and I'm leaving the lease
behavior alone for now.

But I now think that's the right thing to do anyway.  We can always find
a way to expose the new lock type to userspace if Samba would rather use
that instead of leases.  And that way Samba will know whether it's
getting new semantics or old without having to guess based on running
tests or checking the kernel version.

> There might be subtle differences for SETATTR
> as Windows will not revoke them on any update of file information.

I assume the file size would probably still break the OpLock.  But
modifying any other file metadata (permissions, time, ?) wouldn't?

> But Windows revokes them on some more occasions, e.g. if byte-range
> locks are requested on a file,

You wouldn't be able to get a write (exclusive) lock on a read-delegated
file.  We don't bother stating that, though, just because you wouldn't
be able to get a write lock without getting a write open first, and that
would have already broken the delegation.

That results in a delegation recall for NFSv4 as well.  But we don't
need to say that, because you can't get a conflicting byte range lock
without first getting a conflicting open.

> A full and very longish description can be found on MSDN:
> http://msdn.microsoft.com/en-us/library/ff469343%28v=prot.10%29.aspx
> Most important will be the part that starts with "Switch (Operation):"

Thanks!  I'll try to read through it, but more likely I'll need somebody
else to digest it for me....

> The downgrade problem will be the most immediate one to solve, but
> we'll have to look at other potential differences as well.
> Do you have some more information to share about what happens on
> NFSv4 that goes beyond what I was able to find in the RFCs?

RFC 3530 is the right place to start.  Actually, there's a
nearly-completed update that may have some clarifications:

	http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/

Summarizing:

	- Read delegations conflict with other clients' write opens (and
	  therefore also write locks), or any operation by another
	  client that would modify the file's data, metadata, or set of
	  names pointing at the file.
	- Write delegations conflict with other clients' read and write
	  opens (of either type; and therefore also byte-range locks of
	  either type), or any operation (like getattr) by another
	  client that would *read* the file's data or metadata.  But the
	  server can choose not to break a write lease on GETATTR and
	  instead request updated attributes from the client holding
	  the write lease (using a callback, CB_GETATTR).

--b.