Subject: Re: [nfsv4] RFC3530bis: open owner vs. lock owner

From: <[email-masked]>
Date: Tue, 3 May 2011 10:19:27 -0400

To be understandable, recursion must be well-founded.

We need a different word for 
1) the object designated by  lock_owner4/clientid combination
2) the object designated by an open_owner4/clinted combination
3) something that is either 1) or 2).
4) something that owns a lock/stateid, i.e.  A 3) or  a clientid

I you don't do that, you are depending on responding to every case of confusion by saying "well, I warned you this would be confusing".  That's nice, but it doesn't make it much less confusing.

2) is clearly 'open-owner'
3) should be 'lock-owner'
1) is the problem:  "byte-range-lock-owner"? "lock_owner4 object"?

None of the choices for 1) or 4) are great but we need to assign some set of words and use them consistently. 

Another set o choices,  we need different words for are
A) an open 
B)  byte range lock
C) something which is A) or B) (i.e. is owned by a lock owner (in the sense of  (3))
D) a C) o a delegation (or layout) stateid

"open" is obvious for (A) and 'lock is fine for (D).

We simply have to stop using "lock" for (B) and say "byte-range-lock" when we mean (B).

Do we need a word/phrase for (C): "sub-client-scoped lock"?

If we have clear assignments or 1-4) and A-D), then we can be wrong when we apply them,
But at least we won't have text that is "not even wrong".  

-----

> 
>   Unlike the text in NFSv4.1 [31], this text treats "lock-owner" as
>   meaning both a open-owner and a lock-owner.  Also, a "lock" can refer
>   to both a byte-range and share lock.
> 

It would have been better if you were asking me these questions a month
ago when I was struggling with that text. :->

5661 did a major overhaul of the terminology for stateids - it is much
nicer. However, I seem to recall the session id stuff simplified it, but 
that could not be backported to 3530bis.

Lets try to straighten things out:

An open-owner is always an open-owner.

That means we just have to check to see if every remaining lock-owner is referencing
a lock-owner or an open-owner, or both.

And we see instances of both.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Thursday, April 07, 2011 5:35 PM
To: Marcel Telka
Cc: [email-masked]
Subject: Re: [nfsv4] RFC3530bis: open owner vs. lock owner

I've pushed this out to the WG alias because people there might have some
input.

On Apr 7, 2011, at 10:11 AM, Marcel Telka wrote:

> On Thu, Apr 07, 2011 at 04:49:11PM +0200, Marcel Telka wrote:
>> On Thu, Apr 07, 2011 at 09:42:27AM -0500, Thomas Haynes wrote:
>>> 
>>> On Apr 7, 2011, at 9:38 AM, Marcel Telka wrote:
>>> 
>>>>> 
>>>> 
>>>> Thank you, Tom. Is the updated text of the bis document available somewhere?
>>>> 
>>>> -- 
>>>> Marcel Telka
>>>> RPE, Systems
>>> 
>>> 
>>> Sorry, I should have let you know:
>>> 
>>> http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/
>>> 
>> 
>> Great. Thanks.
> 
> I think the text is still confusing. See:
> > 
> > The paragraph above looks like a recursion:
> > To understand recursion you must first understood the recursion. :-)

> 
> The paragraph above looks like a recursion:
> To understand recursion you must first understood the recursion. :-)
> 

I'm fine with changing it to:

This text treats "lock-owner" as
meaning both a open-owner and a lock-owner.  Also, a "lock" can refer
to both a byte-range and share lock.

> 
> Next, the chapter "9.1.4.  lock-owner" is obviously about lock_owner4 only. It
> has nothing to do with open owner. So the definition above does not apply.

No actually it is both a lock-owner and an open-owner. I.e., it describes the
format of both.

Look at Section 9.1.8:

   When a particular lock-owner no longer holds open or file locking
   state at the server, the server may choose to release the sequence
   number state associated with the lock-owner.  The server may make

Clearly the "lock-owner" refers to both an open-owner and a lock-owner.

> 
> Next, chapter "15.39.  Operation 39: RELEASE_LOCKOWNER" contains this:
> 
> ...
> 
>   struct RELEASE_LOCKOWNER4args {
>           lock_owner4     lock_owner;
>   };
> 
> ...
> 
>   This operation is used to notify the server that the lock-owner is no
>   longer in use by the client.  This allows the server to release
>   cached state related to the specified lock-owner.  If file locks,
> 
> ...
> 
> 
> I believe either lock_owner4 or lock_owner should be used there.
> 

Agreed.

> -- 
> Marcel Telka
> RPE, Systems

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 3 May 2011 13:08:32 -0400

> 3) something that is either 1) or 2).

lockowner, openowner, stateowner?

> We simply have to stop using "lock" for (B) and say "byte-range-lock" when we mean (B).

"byte-range-lockowner" is pretty cumbersome, and it doesn't seem that
bad to me to just state that "lock", at least in the context of
"lockowner", means "byte-range lock".

But, whatever, the choice doesn't matter as much as choosing something
and making the definitions explicit....

--b.

---

From: <[email-masked]>
Date: Tue, 3 May 2011 18:33:31 -0400

Thanks to Tom for making us feel that pushing for greater clarity is a worthwhile use of one's time.

His reward is having everybody pushing him for greater clarity.

No good deed goes unpunished.  Sigh!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Monday, April 11, 2011 10:55 AM
To: Marcel Telka
Cc: [email-masked]
Subject: Re: [nfsv4] RFC3530bis: open owner vs. lock owner

On Apr 11, 2011, at 2:21 AM, Marcel Telka wrote:

> On Fri, Apr 08, 2011 at 04:35:59PM -0500, Thomas Haynes wrote:
>> On Apr 8, 2011, at 3:28 PM, Marcel Telka wrote:
>>> <cite from 9.1.5. with my comments inlined>
>>> 
>>>  If the lock-owner performs a READ or WRITE in a situation in which it
>>> 
>>> # lock-owner cannot perform READ or WRITE. only open-owner can.
>>> # I think this paragraph should be reworded.
>> 
>> 
>> But that isn't what the spec states:
>> 
>>   The stateid value for a READ request represents a value returned from
>>   a previous byte-range lock or share reservation request or the
>>   stateid associated with a delegation.  The stateid is used by the
>>   server to verify that the associated share reservation and any byte-
>>   range locks are still valid and to update lease timeouts for the
>>   client.
>> 
>> So if the stateid is from a byte-range lock, then it is from the lock-owner
>> and not the open-owner.
> 
> True. My mistake.
> 

Not gunning for blame assignment. Thanks for pushing for a better
clarity in this area.