[pnfs] [nfsv4] Re: October Bakeathon and Vestigial LockingInfrastructure FromV4.0
Iyer, Rahul
Rahul.Iyer at netapp.com
Fri Sep 14 14:09:47 EDT 2007
I think it might be wise to bring this up on the IETF list. That way we
can get it to their attention early enough so this can make the draft 14
boat.
-Rahul
> -----Original Message-----
> From: William A. (Andy) Adamson [mailto:andros at citi.umich.edu]
> Sent: Friday, September 14, 2007 7:35 AM
> To: Sager, Mike
> Cc: pnfs at linux-nfs.org; NFSv4
> Subject: [nfsv4] Re: [pnfs] October Bakeathon and Vestigial
> LockingInfrastructure FromV4.0
>
> 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.0 while 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.
>
>
>
>
>
>
More information about the pNFS
mailing list