[pnfs] October Bakeathon and Vestigial Locking Infrastructure FromV4.0

Fri Sep 14 10:34:44 EDT 2007

Hi Mike

This is a bit of a long email where I look at each 4.0 operation related to
locking to see what draft 13 says about the operations seqid and clientid
WRT to 4.1, and compare it to what draft 13 says at the bottom of section
8.8.

The result: draft 13 is inconsistent to say the least!

At the end of the day, I agree that the draft 13 intent is to ignore seqid
and clientid for 4.1 for these operations, and to not ignore them for 4.0.

I believe this is what other implementations will bring to the bakeathon,
and so after checking, I will apply your changes.....

Hopefully, draft 14 will address this confusion.

Regards

-->Andy

On 9/13/07, Sager, Mike <Mike.Sager at netapp.com> wrote:
>
>  Hi Andy,
>
> Section 18.10.4 of Draft 13 has this: "The client field of the lock owner,
> and all seqid values in the arguments MAY be any value and MUST be ignored
> by the server"  which is different from that of Draft 10.
>

Yes, but I believe this is supposed to be for 4.1 only, yet the draft does
not say so.
Also, the above section disagrees with 8.8.

For the case described in 8.8 below, the patched code distinguishes between
> 4.0 and 4.1, so I think both cases are covered.
>

Hmmm. Section 8.8 says that in 4.1, the sequenceid and clientid in the
"existing operations related to locking (e.g. OPEN, OPEN_DOWNGRADE, LOCK,
LOCKU, CLOSE)  MUST be set to zero else the server returns NFS4ERR_INVAL.
This directly contradicts section 18.10.4.

The draft is very confusing on how 4.1 deals with 4.0 sequence numbers and
client id's in these operations. Lets look:

The description of OPEN section in 18.16.4 agrees with section 8.8, but the
client ID description (below) does not mention this is for 4.1, not
4.0while the seqid description does mention
4.1 only.

The client ID associated with the owner is
   not derived from the client field of the owner parameter but is
   instead the client ID associated with the session on which the
   request is issued.  If the client ID field of the owner parameter is
   not zero, the server MUST return an NFS4ERR_INVAL error.

    The seqid value is not used in NFSv4.1, but it MAY be any value and
   the server MUST ignore it.

The description of OPEN_DOWNGRADE in section 18.18.4 disagrees with 8.8

  The seqid argument is not used in NFSv4.1, MAY be any value, and MUST
   be ignored by the server.

The description of LOCK in section 18.10.4 disagrees with 8.8, but the
section (below) does not stipulate that it is describing what 4.1 does, not
4.0

The client field of the lock owner, and all seqid values in the
   arguments MAY be any value and MUST be ignored by the server.  The
    client ID with which all owners and stateids are associated is the
   client ID associated with the session on which the request was
   issued.  The client ID appearing in a LOCK4denied structure is the
   actual client associated with the conflicting lock, whether this is
   the client ID associated with the current session, or a different
   one.

The description of CLOSE in section 18.2.4 disagrees with section 8.8, but
the section (below) does not stipulate that it is describing what 4.1 does,
not 4.0

   The argument seqid MAY have any value and the server MUST ignore
    seqid.

the description of LOCKU in section 18.12.4 disagrees with section 8.8, but
the section (below) does not stipulate that it is describing what 4.1 does,
not 4.0

  The seqid parameter MAY be any value and the server MUST ignore it.

Mike
>
>  -----Original Message-----
> *From:* William A. (Andy) Adamson [mailto:andros at citi.umich.edu]
> *Sent:* Thursday, September 13, 2007 1:09 PM
> *To:* NFSv4
> *Cc:* pnfs at linux-nfs.org
> *Subject:* [pnfs] October Bakeathon and Vestigial Locking Infrastructure
> FromV4.0
>
> Just a note that draft-ietf-nfsv4-minorversion1-13.txt has not changed the
> draft-ietf-nfsv4-minorversion10.txt language concerning the requriement to
> zero sequence id's and client id's in existing operations related to locking
> (OPEN, LOCK, LOCKU, etc).
>
> Since the October Bakeathon uses draft-ietf-nfsv4-minorversion1-13.txt, we
> expect this behaviour. Maybe I missed something - but I thought that at the
> Austin bakeathon it was decided that the server could ignore vestigial
> locking sequence id and client ids....
>
> -->Andy
>
> >From draft-ietf-nfsv4-minorversion1-13.txt,
> 8.8.  Vestigial Locking Infrastructure From V4.0
>
>           .......................
>
>    Also, there are a number of fields, present in existing operations
>
>
>
> Shepler, et al.          Expires January 2, 2008              [Page 160]
> ^L
> Internet-Draft            NFSv4 Minor Version 1                July 2007
>
>
>    related to locking that have no use in minor version one.  They were
>    used in minor version zero to perform functions now provided in a
>    different fashion.
>
>    o  Sequence ids used to sequence requests for a given state-owner and
>       to provide retry protection, now provided via sessions.
>
>    o  Client IDs used to identify the client associated with a given
>       request.  Client identification is now available using the client
>       ID associated with the current session, without needing an
>       explicit client ID field.
>
>    Such vestigial fields in existing operations should be set by the
>    client to zero.  When they are not, the server MUST return an
>    NFS4ERR_INVAL error.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20070914/26d80e6e/attachment-0001.htm 