Subject: RE: RELEASE_STATE locking type

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 11 Mar 2002 06:56:28 -0800

I think these are reasonable answers but the result is kind 
of ugly.  Thinking about this some more, I've come to the
conclusion that the ugliness is inherent in using the wrong
tool (LOCKU) to do RELEASE_STATE.  RELEASE_STATE doesn't unlock
anything, and it's parameters are entirely different that those
for unlock.  

How about this?  RELEASE_STATE is made a new op.  It has the
parameters open_stateid, open_seqid, and lockowner.  Nothing
(except the error status) is returned.  If you do this, then ...

You don't have a locktype that is invalid in almost all contexts
except one (LOCKU).

You don't have parameters that are passed but ignored (offset,
length).  

You don't return data that is undefined and the client needs to
ignore.

You don't need any special exceptions to do the sequencing logic.
In this model, the sequencing information is stored in a context
that is not destroyed by the operation (the openowner context),
so everything works normally.  This is appropriate since 
RELEASE_STATE is the join correspnding the fork done by the
from_open case of LOCK.  In the latter case, the sequence
information is relative to the openowner context since the
openowner is what we are changing by forking off a new state 
sequence.  Similarly, when we terminate the lock state sequence 
and merge it back to the open, the openowner sequence context
is also the appropriate one.

Of course my readiness to completely re-organize this fucntion 
might have something to do with the fact that I haven't implemented
or started implementing the one that is currently in the .x file.
If people are attached to the current approach (because of having
implemented it or otherwise), I can implement what's in the current
.x and live with the ugliness.

Opinions?

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Saturday, March 09, 2002 11:44 PM
To: [email-masked]
Subject: Re: RELEASE_STATE locking type

On Sat, Noveck, Dave wrote:
> 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?).

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

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

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.

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

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

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

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.

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

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

---

From: "Dan Trufasiu" <[email-masked]>
Date: Mon, 11 Mar 2002 11:44:04 -0500

Hi,

My opinion is that we don't need RELEASE_STATE. Do somebody use it? As we
just realized, without a strong wording in the protocol, this flag will be
used in the future implementations as a REALESE_ALL. I don't think that the
client has to take responsibilities in the cleaning of the server. I'm just
curious: How a client can decide efficiently that an application will not
lock a file anymore?

Dan

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Noveck, Dave
> Sent: Monday, March 11, 2002 9:56 AM
> To: [email-masked]'; [email-masked]
> Subject: RE: RELEASE_STATE locking type
>
>