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

From: Thomas Haynes <[email-masked]>
Date: Thu, 7 Apr 2011 16:34:38 -0500

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

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

---

From: Marcel Telka <[email-masked]>
Date: Fri, 8 Apr 2011 14:12:24 +0200

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

Ok. Thanks.

> ago when I was struggling with that text. :->

:-)

It would be better the original authors of 3530 did better job with the text
update after they invented the open owner.

> that could not be backported to 3530bis.

I never read 5661 so I cannot agree or disagree. :-)

> An open-owner is always an open-owner.

Good.

> to both a byte-range and share lock.

The removal of NFSv4.1 reference will not fix the recursion issue.

What about walking through all of the text and where "lock owner and open
owner" should be referred, just use "L-O and/or O-O" instead of current "L-O".
Yes, I know the current wording is inherited from 3010...

The overloaded term "lock-owner" will always cause troubles.

Another example I found:

8.1.8.  Use of Open Confirmation

   In the case that an OPEN is retransmitted and the lock_owner is being
   used for the first time or the lock_owner state has been previously
   released by the server, the use of the OPEN_CONFIRM operation will
   prevent incorrect behavior.  When the server observes the use of the
   lock_owner for the first time, it will direct the client to perform
   the OPEN_CONFIRM for the corresponding OPEN.  This sequence
   establishes the use of an lock_owner and associated sequence number.
   Since the OPEN_CONFIRM sequence connects a new open_owner on the
   server with an existing open_owner on a client, the sequence number
   may have any value.  The OPEN_CONFIRM step assures the server that
   the value received is the correct one.  See the section "OPEN_CONFIRM
   - Confirm Open" for further details.

The lock_owner above should refer to open-owner only. lock_owner has nothing
with OPEN_CONFIRM.

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

In 9.1.8, yes. The lock-owner refers both. But in 9.1.4. the lock-owner refers
just lock_owner (IMHO):

   When requesting a lock, the client must present to the server the
   client ID and an identifier for the owner of the requested lock.

Yes, the paragraph can mean open-owner too, but it has no added value. The
open-owner mechanics is covered in detail in 9.1.9.

-- 
Marcel Telka
RPE, Systems

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 8 Apr 2011 15:08:00 -0500

> Yes, I know the current wording is inherited from 3010...

How about:

open-owner always means open-owner
lock-owner always means lock-owner
state-owner always means either the open-owner or the lock-owner

We already use state-owner about 5 times in that context.

I..e, I'm looking at section 9.1.5.  Use of the Stateid and Locking
and it reads cleaner if we say state-owner instead of "L-O and/or O-O"

> The lock_owner above should refer to open-owner only. lock_owner has nothing

Agreed and changed.

---

From: Marcel Telka <[email-masked]>
Date: Fri, 8 Apr 2011 22:28:32 +0200

> state-owner always means either the open-owner or the lock-owner

Very good idea to invent something new!
+1

I believe the definition of all three above terms (*-owner) should be placed at
beginning of the RFC. For example in 1.6.

I found this in 1.6.:

   Lock:  The term "lock" is used to refer to both record (byte-range)
      locks as well as share reservations unless specifically stated
      otherwise.

It means that the last sentence here (in 9.1.1.):

can be safely removed.

> and it reads cleaner if we say state-owner instead of "L-O and/or O-O"

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

   has established a lock or share reservation on the server (any OPEN
   constitutes a share reservation) the stateid (previously returned by

# what stateid? open stateid or lock stateid?

   the server) must be used to indicate what locks, including both byte-
   range locks and share reservations, are held by the lockowner.  If no

# lockowner - one word. wow! (I found such oneword at several places in
# the bis)

   state is established by the client, either byte-range lock or share
   reservation, a stateid of all bits 0 is used.  Regardless whether a
   stateid of all bits 0, or a stateid returned by the server is used,
   if there is a conflicting share reservation or mandatory byte-range
   lock held on the file, the server MUST refuse to service the READ or
   WRITE operation.

-- 
Marcel Telka
RPE, Systems

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 8 Apr 2011 16:35:59 -0500

> Very good idea to invent something new!

Not my idea, done by the authors of 3530 when they did 5661.

>   to both a byte-range and share lock.

Yes, I had already done that in my working copy.

These were somewhat already there in the Introduction, but I'll call them out as:

   Stateid:  A stateid is a 128-bit quantity returned by a server that
      uniquely defines the open and locking states provided by the
      server for a specific open-owner or lock-owner/open-owner pair for
      a specific file and type of lock.

      lock-owner:  An owner of a byte-range lock.

      open-owner:  An owner of an open.

      state-owner:  Either a lock-owner or an open-owner.

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

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 08 Apr 2011 14:59:32 -0700

>       uniquely defines the open and locking states provided by the
                 ^^^^^^^ identifies
>       state-owner:  Either a lock-owner or an open-owner.

Erm.... The stateid may also represent a delegation, which is a form of
"lock" with no associated state owner.

In RFC5661, you also have the case of layout stateids.

If I was trying to describe a stateid, I'd probably start by describing
the general concept as being literally something that is used to label
the present (or past) state of an object. Then you can narrow it down to
the specific examples such as file share locks, byte range locks, and
delegations...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 08 Apr 2011 14:59:32 -0700

^^^^^^^ identifies

NetApp

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 08 Apr 2011 14:59:32 -0700

^^^^^^^ identifies

NetApp

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 8 Apr 2011 17:51:37 -0500

> "lock" with no associated state owner.

So "delegation-owner"?

;->

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 8 Apr 2011 17:54:52 -0500

> the specific examples such as file share locks, byte range locks, and

Yeah and that is not where I want to go at all. I've pulled out the "*-owner"
from above and I'm going to let the document stand as is.

We don't define 'state-owner' in 5661 and yet we can all figure it out.

---

From: Marcel Telka <[email-masked]>
Date: Mon, 11 Apr 2011 09:21:24 +0200

> So if the stateid is from a byte-range lock, then it is from the lock-owner

True. My mistake.

-- 
Marcel Telka
RPE, Systems

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 11 Apr 2011 09:54:31 -0500

>> So if the stateid is from a byte-range lock, then it is from the lock-owner

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