Subject: Changes for CLOSE_ALL operation

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 4 Jan 2000 11:06:59 -0800

These are the changes to introduce a CLOSE_ALL operation.
CLOSE_ALL addresses some of the recovery problems that 
arise when you give up on processing on an lcoking-related
RPC.  The problem is that you may wind up unable to access
a stateid in a response to an OPEN (for example) when you
give up on the OPEN RPC.  Thsi means you may not be able
to get rid of the associated lock which is going to be 
subject to implcicit lease renewal with all your other
locks, the ones you know about.

This is all relative to draft-03.

----

Add an new section after 8.5.3:

8.5.4.  Timeout or other aborts of locking RPC's

    In cases where network congestion or other communication
    problems cause significant delays but the problems do not
    constitute a network partition, timing out of a locking
    RPC's or aborting such an RPC when the process for which
    it was issued is terminated (e.g. in UNIX due to a signal),
    may pose recovery issues for the client.

    In the event that the OPEN or LOCK is eventually acted on,
    a lock will be created that the client has no way of knowing
    about and no way of releasing, since it will not know the 
    proper stateid to use.
 
    Such a lock will be included with the clients other locks 
    and so be subject to implicit lease renewal with all of the
    other locks held by the client, the fact that the client has
    no knowledge of such a lock notwithstanding.  The result may
    be to prevent other clients from obtaining locks in conflict
    with the "lost" lock.

    The CLOSE_ALL operation can be used as part of process 
    termination when such a situation may exist.  It allows all
    of the locks for a given lockowner to be released even 
    those that the client may not be aware because RPC's were
    aborted early.

Add a new section:

14.2.xx.  Operation yy: CLOSE_ALL - Release all locks for a lockowner

  SYNOPSIS

     owner ->

  ARGUMENT

     struct CLOSE_ALL4args {
		nfs_lockowner4	owner;
     };

  RESULT

     struct CLOSE_ALL4res {
		nfsstat4	status;
     };

  DESCRIPTION

     The CLOSE_ALL operation release all locks (both record
     locks and share reservations) held by the specified 
     lockowner.  It is intended mainly as a recovery device
     to allow the client to deal with uncertainty as to the
     proper locking state which arises which a locking 
     operations (such as LOCK or OPEN) is part of RPC and
     that RPC is aborted on the client resultng in siutation
     in which the server response is not available to the client. 

  ERRORS

     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE_CLIENTID

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 06 Jan 2000 13:27:43 -0600

I will be adding the following to the I-D but will be
changing the name of the operation to RELEASE_ALL to
differentiate from CLOSE.

Let me know if there are specific or general problems 
with this proposal.

Spencer

---

From: Mike Kupfer <[email-masked]>
Date: Thu, 06 Jan 2000 11:54:55 -0800

RELEASE_ALL (as Spencer has renamed it) addresses what I expect to be
the common case: the client fails to get the lock and the application
bails out and exits.  That's good.

Unfortunately, it's possible for the application to take a signal
(thereby aborting the current lock request), catch the signal, and
then resume operation.  It seems to me that any time the client aborts
a LOCK or LOCKU call before receiving a reply, it needs to
resynchronize with the server.  After poking through Section 8 a
couple times, I don't see how the client tells the server "there may
be a problem, let's resynchronize locking state".  Am I missing
something, or is this a hole in the protocol?

mike