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

[Spencer Shepler]

On Sep 14, 2007, at 9:34 AM, William A. (Andy) Adamson wrote:

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

I will see what I can get cleaned up.

Spencer


> 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.
>
>
>
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs