Subject: RE: RELEASE_STATE locking type

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 9 Mar 2002 09:46:48 -0800

Spencer Shepler wrote: 
> On Mon, Sergey Klyushin wrote:
> > I looked through the mailing list and could not find description
> > of RELEASE_STATE locking type.
> > Could somebody explain this locking type?
>
> The RELEASE_STATE enum of nfs_lock_type4 is meant as a method for the
> client to communicate to the server that a particular lock_owner will
> non longer be locking the file.  Generally, this would be used by a
> client who has a file open among several processes and one of those
> processes is exiting and has locked the file in the past.  The client
> sends this to the server to notify it that the lock_owner will no
> longer lock the file.  The server is then able to release the state
> associated with that lock_owner.

Is this type intended to be specified in a LOCK request or a LOCKU?
I'm assuming that specifying it in a LOCKT is an error (NFS4ERR_INVAL?).

If specified in a LOCK, I would assume that setting reclaim or 
new_lock_owner makes the request invalid.

Also I'm assuming that offset and length are ignored.

What about the stateid returned?  Is the server supposed to set to
anything in particular (e.g. all zeros)?

There is an issue with RELEASE_STATE and our old friend, retry after
lost reply.

If a locking operation is re-issued, then the sequence information would
normally allow the server to determine that it is a duplicate and allow
fetching of the response information saved for the last operation associated
with that owner.  In the case of RELEASE_STATE, the server would have
released that information, including the sequence information and anything
that would enable the stateid to find that previous-operation information 
which has been freed anyway.  That's the purpose of the whole operation
after all.

This situation is somewhat analogous to a retransmitted CLOSE but the
difference is that with a CLOSE, you have an owner scope (and thus the
scope in which seqids are interpreted) which is larger.  You can
leave the state structure around, pending its deallocation when the 
netx new operation for that owner arrives.  In the case of RELEASE_STATE,
there will never be any such next operation.  The RELEASE_STATE is the
last one.

So I can't see anything happening but that the second RELEASE_STATE
will not be able (or may not reliably be able) to find information 
corresponding to the stateid it recieves.  So I would expect it to return
BAD_STATEID.  In this situation, the client could accept that as an
indication that there is no STATE to release any more (and he generally
would be right).  On the other hand, it seems really ugly for the
client to ignore such an error.  Maybe the server should return OK in
this case, since he has been asked to release all of the asscoiated
state for that lock stateid and if the lock stateid isn't valid, there 
isn't any, so he has released all there is.  Of course, that seems 
pretty ugly too.  I think we need to pick one of these ugly alternatives
and go on. (Unless someone has a bright idea). 

> This is not meant to be a way for the client to release all locks for
> a particular file.  The client is still responsible to do this.  In
> fact, if the client were to use RELEASE_STATE when file locking state
> is still held for the lock_owner, the server should return an error to
> the client.  NFS4ERR_INVAL appears to be the most appropriate error.

I propose we rename NFS4ERR_INVAL to be 
NFS4ERR_YOU_DID_SOMETHING_WRONG_AND_I_AM_NOT_GOING_TO_TELL_YOU_WHAT_IT_IS :-)

-- 
Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Sat, 9 Mar 2002 22:43:43 -0600

> I'm assuming that specifying it in a LOCKT is an error (NFS4ERR_INVAL?).

When I suggested as a solution that Kendrick raised (releasing state
at the server), I was thinking strictly of LOCKU.

> Also I'm assuming that offset and length are ignored.

I would suggest we limit it to LOCKU to reduce semantic
interpretation.  So for LOCK and LOCKT, the server would return
NFS4ERR_INVAL.

For LOCKU with RELEASE_STATE, the offset and length are ignored.

> anything in particular (e.g. all zeros)?

We could suggest all zeros but may leave it as "undefined".  Any
strong preference?

> and go on. (Unless someone has a bright idea). 

Good catch.  Since the use of RELEASE_STATE is meant as a method of a
nice client informing the server about the release, my preference
would be to have the server return NFS4_OK in the case that there is
no match for the stateid supplied by the client.

However, if there is a match on the stateid, the server should apply
the traditional logic towards checking of the sequence-id.

> NFS4ERR_YOU_DID_SOMETHING_WRONG_AND_I_AM_NOT_GOING_TO_TELL_YOU_WHAT_IT_IS :-)

I would go for that except the corresponding line in the .x file would
extend beyond 80 characters. :-)

Another, shorter suggestion?  How about NFS4ERR_PSTPPHHH? (a mimic of
the sound of the cartoon character sticking its toungue out)

-- 
Spencer