Re: [nfsv4] "Courtesy locks"

On Tue, Sep 14, 2010 at 03:55:30PM -0400, david.noveck@emc.com wrote:
> > I think the idea was that you could revoke only those locks that had
> to
> > be thrown away due to conflict, return EXPIRED, and then allow
> reclaims
> > only of those locks that you hadn't been forced to revoke. 
> 
> I think the word "reclaim" is being used in a confusing way, or I'm
> confused, or both.
> 
> While I think you could argue that it is reasonable to use the word
> "reclaim" for any situation in which you try to get back a lock that was
> lost due to lease expiration or any other cause, I think this adds to
> confusion.  I suggest something like "re-establish" and reserve
> "reclaim" for the case in which you use a reclaim-type OPEN or LOCK
> operation (typically during the grace period).

Yes, agreed, and that's the sense which I meant in the above.

> BTW, the spec does allow you to honor reclaim-type operations after the
> grace period if you can be sure that no conflicting lock could have been
> granted from the time the server came up until that OPEN.  (Conflicting
> locks before the server booted this time are domain of "edge
> conditions").  In general, getting that assurance is very difficult,

Well, if there's been no server reboot--if a client just expires and the
server hangs on to only those locks (and opens) that don't see
conflicts--that may be another case where may be able to selectively
grant reclaims without a whole lot of work.

--b.

> but
> in the often common case in which OPENs with anything other than
> DENY=NONE are very rare, you can do something very simple.
> 
> If the RECLAIM open is with DENY=NONE, and there has never been an open
> with anything other than DENY=NONE, then there could have not been any
> such lock granted, and you can grant the RECLAIM-type open.  In less
> restrictive circumstances things get more difficult but depending on
> what information you are willing to save (lists of fh's with various
> sorts of locks), you may be able to handle a large proportion of clients
> that would otherwise fall victim to expiration of the grace period and a
> consequent inability to reclaim their locks. 
> 
> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
> Of J. Bruce Fields
> Sent: Tuesday, September 14, 2010 1:07 PM
> To: Rick Macklem
> Cc: nfsv4@ietf.org
> Subject: Re: [nfsv4] "Courtesy locks"
> 
> On Mon, Sep 13, 2010 at 09:13:30PM -0400, Rick Macklem wrote:
> > > 
> > > But if the server is not allowed to process reclaim ops outside the
> > > grace period then there's no hope of nicely handling the case where
> > > the server's grace period passes before the client gets a chance to
> > > reconnect to the server.
> > > 
> > 
> > Yep. But grace periods must be greater than a lease duration and I'd
> > assume clients will be trying hard to re-connect.
> > 
> > > In the context of "courtesy locks" I don't think it makes any sense
> > > for a server to keep the state around if it's going to tell the
> client
> > > that the state expired but not allow the state to be reclaimed.
> > > (Wasn't the point of the "courtesy" to allow them to be reclaimed if
> > > there hadn't been any contention?)
> > > 
> > 
> > What the FreeBSD server does (and what I assumed was meant by courtesy
> > lock) is retain the state after the lease has expired (so long as no
> > conflicting request is received)so that the state is still valid at
> > the server and NFS4ERR_EXPIRED does not need to be replied to the
> client.
> > 
> > I'd appreciate hearing, if others have a different understanding of
> it.
> 
> I think the idea was that you could revoke only those locks that had to
> be thrown away due to conflict, return EXPIRED, and then allow reclaims
> only of those locks that you hadn't been forced to revoke.
> 
> --b.
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 