Subject: RE: interpretation of LOCK usage (open_to_lock_owner4 usage)

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 12 Dec 2002 13:39:19 -0800

Good point.  

Given the complexity of these issues, I think I'm going to code
up a test program, that tries these cases.  I have a simple
framework, called v4t, in which it is relatively easy to write 
a c++ program (relativey easy given that I wrote them I mean, no
generally available framework) that does wierd client-type v4
things.  So, based on your examples, expect to see the program 
v4t_spencer running at connectathon.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 4:19 PM
To: [email-masked]
Subject: Re: interpretation of LOCK usage (open_to_lock_owner4 usage)

I need to point out that the client under error conditions does have a
valid reason to send a LOCK(new_lock_owner) request where one was sent
previously.

This is the case where the initial LOCK request received errors like:
NFS4ERR_DENIED, NFS4ERR_GRACE and the client is going to retransmit
the request with a new open_owner sequence id, etc.

In this case, the server will need to accept this request.  So the
qualification on my scenario below is that the LOCK request succeeded
with NFS4_OK and then subsequent LOCK(new_lock_owner) with the
existing lock_owner/file pair is invalid.

On Thu, Noveck, Dave wrote:
> I definitely agree that this should be an error.
> 
> The spec is not very clear on this issue so it is hard to
> tell what error is "right".  Since this doesn't really fit 
> in any of the categories, you could argue INVAL but that 
> would make it really hard for the client to find out what
> is wrong.  I think BAD_SEQID is probably the best choice.
> 
> It looks like my code returns OLD_STATEID in this case and 
> that seems really bogus.  I'll change it to BAD_SEQID or
> whatever else turns out to be the general consensus.  
> 
> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 4:08 PM
> To: [email-masked]
> Subject: interpretation of LOCK usage (open_to_lock_owner4 usage)
> 
> 
> I am posting to convey my interpretation of dealing with a particular
> scenario involving LOCK operation usage.
> 
> The scenario is:
> 
> Client sends a LOCK with the new_lock_owner specified and provides a
> lock_owner (LO1).  The server responds to this appropriately.
> 
> The client send zero or more LOCK/LOCKU operations but does not send a
> RELEASE_LOCKOWNER operation for LO1 and the file is still open.
> 
> The client sends a new LOCK request with new_lock_owner specified and
> provides the same lock_owner (LO1) as in the first LOCK request.
> 
> The question is what does the server do with this second LOCK request.
> since the second LOCK request is using an "established" lock_owner and
> potentially specifying a new lock_seqid.
> 
> For this case, I am coding our server to return NFS4ERR_BAD_SEQID
> therefore forcing the client to appropriately track its use of a
> lock_owner/file association.
> 
> Comments?
> 
> Spencer

-- 
Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 12 Dec 2002 16:38:18 -0600

On Thu, Dean Hildebrand wrote:
> Currently we simply treat this case as an error in trying to create a 
> duplicate state id and return the error ERR_BAD_STATEID.  
> ERR_BAD_SEQ doesn't really make sense since it is the clients fault for 
> trying to create a lock (and lockowner) twice.  A new error code might be 
> more helpful for debugging but I digress....

NFS4ERR_BAD_SEQID is an indication that the client has chosen a
sequence that does match the server's view of the received/processed
requests.  It indicates a client error.  The use of BAD_STATEID does
not seem appropriate since the stateid is not BAD its the use of the
stateid in this particular context that is inappropriate.

I will agree that an additional error would be helpful but BAD_SEQID
is what we have at hand.

Spencer