Subject: RE: LOCK,LOCKT,LOCKU

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 14 Dec 1999 11:45:43 -0800

Spencer Shepler wrote:
> "Noveck, Dave" wrote:
> 
> > As far as args,
> > 
> >      LOCKT and LOCKU have a lockowner instead of a
> >      stateid.  You could get the owner from the stateid
> >      if you actually have some lock on the file.  Also,
> >      having LOCKU take a lockowner rather than a stateid
> >      would (I think) allow you to unlock locks in a case
> >      some leases had expired, since without a stateid,
> >      you won't get a EXPIRED error on the stateid.  I
> >      would vote to keep LOCKT and LOCKU as having a
> >      lockowner, as described in the spec, rather than
> >      as they currently are in the .x file.
> 
> If the lease has expired, the lock will no longer exist
> and the client won't have a need to do a LOCKU, right?

I think I need to be more careful here and distinguish 
between lease expiration and revocation, with revocation
either happening within the lease period or after expiration
when the server decides to grant a conflicting request.

After expiration, the lock may continue to exist.  The
revalidation procedure for possibly expired locks is 
going to give it a new lease (on life!).  The point
is that in this state, the locks is addressable by
means of the associated stateid.

If you have lease expiration, and the lock is revoked
because of a conflicting request, then the lock ceases
to exist, in that it no longer denotes any active rights
with regard to a file.  The associated stateid becomes
invalid in that any use of it will result in NFS4ERR_EXPIRED.
What needs to be decided is what the correct recovery path
from this situation is.  With the new stateid errors
codes, you need to distinguish between a stateid 
containing expired/revoked locks and one which is simply
bad (i.e. does not currently denote anything at all)
so there needs to be a way to allow the server to know
that the client no longer uses that stateid to denote
the locking state of the file.
  
> I have changed LOCKT to pass nfs_lockowner but not LOCKU
> (still stateid).

OK.  I think the right way to do this is to allow a stateid
on CLOSE to work even if it denotes some revoked locks.
All locks that still exist should be defined to go away 
(or something similar; David Robinson had a precise formulation 
in mind on the issue of CLOSE while there are still existing
locks), but the point is that client is telling
the server that he is done with this file and the 
associated stateid.