Re: [nfsv4] "Courtesy locks"

> 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).

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, 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