Subject: RE: help re: V4 locking

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 31 Oct 2001 14:48:32 -0800

> Help...
> 
> I've finally gotten to the stage where I'm trying to implement the locking
> part of V4 (I've been avoiding this for quite a while:-) and after looking
> at the spec, I'm basically confused.

> So here are some pretty basic questions that someone might be willing to
> answer:

I assume you are looking at RFC3010.  There are currently a number of
changes to the protocol that are so far only documented in a .x file.
See http://www.nfsv4.org/rfc3010updates/nfs4_prot.x

The fundemental concepts haven't changed so the answers to your questions
aren't changed too much.

> 1 - Does a stateid refer to a lock owner or a <lock_owner,file_lock>?
>     (In one place, the spec mentions "a stateid is a shorthand for a
>     lock owner", in others it seems to imply it refers to a specific
>     lock for an owner.)

The stateid refers to the set of locks on a given file held by a given
lockowner.  In this context, locks include both opens and byte-range
locks.

In the newer protocol, this has been slightly modified in that opens
and byte-range locks are separated but the idea that a stateid 
represents a set of locks on a given file held by a given owner.
 
> 2 - Why is a stateid an argument to the LOCK subop and where has it come
>     from? (Is it assumed that an OPEN has happened first?)

It comes from the last operation that returned a stateid for that 
combination of lockowner and file, which can be an OPEN, OPEN_DOWNGRADE,
LOCK or LOCKU.

In the newer protocol, this is similar although there are two
explicit options to deal separately with the cases of a stateid 
that came from LOCK or LOCKU vs. one that came from OPEN or
OPEN_DOWNGRADE.

> 3 - What stateid is returned by LOCK, LOCKU? (Is it just the stateid that
>     was provided as an argument, so the client can verify which succeeded
>     or is it meant to be a new one that represents updated lock state?)

Although it isn't explicitly required, the idea is that the server may
change the stateid so that it can determine when an out-of-date stateid
is received (typically on a READ or WRITE request).

In the newer protocol this will be required and the stateid has a defined
sequence field to deal with this, rather than having it buried with a
purely opaque stateid.

> Anyhow, thanks in advance for any help, rick
> ps: If there is some supporting doc that explains this, please let me know.