Subject: [nfsv4] lock_seqid incrementing

From: Ian Schorr <[email-masked]>
Date: Wed, 23 Dec 2009 17:08:05 +1100

Hello list,

So today's task is to spend some time understanding NFSv4 state
handling and sequencing a bit better than I do.  It's a monster =)

Here's one thing that's been breaking my brain, and was hoping someone
could clarify for me.

Section 8.1.5. of RFC 3530 defines, as far as I can tell, lock
sequencing rules specifically about the lock_seqid (and NOT the
open_seqid).  It mentions, for example, that the (vaguely referred to)
"sequence number" should be initialized at zero for a given
lock_owner.  And "each lock request contains a sequence number that is
a consecutively increasing integer.  Different lock_owners have
different sequences."  Okay.

However, the same section, referring only to "sequence number" the
whole time, goes on to say:

"The client MUST monotonically increment the sequence number for the
   CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
   operations."

...Now, if we're talking about the lock_seqid (which has an
independent sequencing space per lock_owner) and not the open_seqid,
how could lock_seqid be incremented for a given OPEN or CLOSE request,
which don't include the lock_owner info defined from a LOCK request
that lock_seqid is associated with?

Seems like this section is talking about the open_seqid?  Is that correct?

If that section is NOT talking about the open_seqid, then where are
the sequencing rules for open_seqid defined?  I haven't found those
yet.  Or if this section is talking about the sequence incrementing
rules for open_seqid, where are rules for lock_seqid defined?

Or do I have this all mixed up?

And actually, one more question...Is there documentation somewhere
that defines how a server should behave depending on the value of
new_lock_owner in a request?  The RFC seems to mention that it exists
and I see that the structure of LOCK requests differs depending on its
value, but what should the server do if it's set to FALSE?  If it's
set to "true", should the server make any assumptions about state of
the lock_owner mentioned other than to determine whether the structure
that follows contains a lock_owner?  What's the point of this option?

Thanks,
Ian Schorr

---

From: Rick Macklem <[email-masked]>
Date: Wed, 23 Dec 2009 12:03:25 -0500 (EST)

> that lock_seqid is associated with?

Each open_owner and each lock_owner have a sequence id# associated with 
it, that is used to serialize state changing operations related to that
open_owner/lock_owner. (The RFC tends to use lock_owner to refer to both
open_owner4 and lock_owner4.) The above refers to both open and lock owner
cases.

One quirky case is that Close refers to "outstanding locks on CLOSE". I
believe (and I think I convinced others of this) is that the locks 
referred to by this are those for the lock_stateid created from a Lock
Op using the new_lock_owner case of the Lock Op. As such, there can be
multiple "instances" of the same lock_owner4 string, but each are
associated with different OpenStateIDs.

> that follows contains a lock_owner?  What's the point of this option?
new_lock_owner == True when that lock_owner4 string does not yet have
a LockStateID (created by a previous Lock Op with new_lock_owner == True)
or when the locks for the lock_owner4 string are to be "related" to a
different OpenStateID for the Close Op.

When new_lock_owner == True, the Lock Op is being ordered using the
sequence id# of the OpenStateID/open_owner4 and not the sequence id#
of the lock_owner4. (The lock_seqid in open_to_lock_owner4 is the
initial value of the lock sequence# for the newly created LockStateID.
The RFC seems to state it should always be 1, but my server doesn't
get upset if the value isn't 1. I think clients should always set this
to 1 to play it safe.)

Good luck with understanding NFSv4.0 lock state handling (you'll need
it:-).

Have a good holiday, rick

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 24 Dec 2009 14:21:37 -0800

On Tue, December 22, 2009 10:08 pm, Ian Schorr wrote:
> open_seqid). 

Neither. The section is discussing the "seqid" argument of the
operations it lists.Each open-owner or lock-owner has its own
sequence. The open-owner or lock-owner is identified by the
explicitly by an open- or lock- owner or a stateid. Unfortunately
seqid is also a field in a stateid which is an unending source of
confusion. This is part of the reason why all new data types
in NFSv4.1 use a unique prefix for all fields, and why when
I'm asked to review code, I refuse to do so, unlike a prefix
convention is adopted for new structs and new fields of old
structs that didn't have a prefix convention.

> It mentions, for example, that the (vaguely referred to)

The server should use the stateid in lock_owner.lock_stateid.

> that follows contains a lock_owner?

I don't understand the question.

> What's the point of this option?

The point relates to a how POSIX/UNIX defines byte-range locking
semantics. Byte-range locks are tied to a process ID and are not
inherited when a process forks. Whereas, open file descriptors
are tied to the credential that opened the file, and file
descriptors are inherited when a process forks. When a byte-range lock is
created, we need to establish a lock-owner, i.e. create a stateid for
a file's byte range lock.

My understanding is that Windows semantics are different ... not sure
how exactly, but nonetheless, NFSv4 if flexible enough to handle
either semantic.

>
> Thanks,
> Ian Schorr
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/