Is kernel oplocks = yes a good default?

[Christian Ambach]

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

I think those pretty much correlate with what would be reasons for 
revocation on Windows. There might be subtle differences for SETATTR as 
Windows will not revoke them on any update of file information.

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

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):"

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?

Maybe that would help creating a table of differences and similarities.

Cheers,
Christian