[pnfs] [nfsv4] Re: October Bakeathon and Vestigial LockingInfrastructure FromV4.0
Spencer Shepler
Spencer.Shepler at Sun.COM
Fri Sep 14 14:16:41 EDT 2007
Heh, he did; nfsv4 at ietf.org is cc'd.
Spencer
On Sep 14, 2007, at 1:09 PM, Iyer, Rahul wrote:
> 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.
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
More information about the pNFS
mailing list