Re: [nfsv4] layout stateid handling/processing updates

[Benny Halevy <bhalevy at panasas.com>]

To make sure, we intend to implement this feature in linux,
server and client for the May Connectathon.

Who else is planning that?

Benny

On Apr. 08, 2008, 17:27 +0300, Spencer Shepler <Spencer.Shepler at Sun.COM> wrote:
> Assuming no discussion means rough consensus for these changes, they
> will be part of the next I-D.
> 
> Spencer
> 
> On Apr 4, 2008, at 2:13 PM, Spencer Shepler wrote:
>> Updated section based on recent discussion:
>>
>> -----
>>
>>> 12.5.5.2.1.4.  Wraparound and validation of sequence id
>>>
>>>    The rules for layout stateid processing differ from other  
>>> stateids in
>>>    the protocol because the "seqid" value can not be zero and the
>>>    stateid's "seqid" value changes in a CB_LAYOUTRECALL  
>>> operation.  The
>>>    non-zero requirement combined with the inherent parallelism of  
>>> layout
>>>    operations means that a set of LAYOUTGET and LAYOUTRETURN  
>>> operations
>>>    may contain the same value for "seqid".  The server uses a  
>>> slightly
>>>    modified version of the modulo arithmetic as described in
>>>    Section 2.10.5.1 when incrementing the layout stateid's  
>>> "seqid".  The
>>>    modification to that modulo arithmetic description is to not use
>>>    zero.  The modulo arithmetic is also used for the comparisons of
>>>    "seqid" values in the processing of CB_LAYOUTRECALL events as
>>>    described above in Section 12.5.5.2.1.3.
>>>
>>>    Just as the server validates the "seqid" in the event of
>>>    CB_LAYOUTRECALL usage, as described in Section 12.5.5.2.1.3, the
>>>    server also validates the "seqid" value to ensure that it is  
>>> within
>>>    an appropriate range.  This range represents the degree of
>>>    parallelism the server supports for layout stateids.  If the  
>>> client
>>>    is sending multiple layout operations to the server in  
>>> parallel, by
>>>    definition, the "seqid" value in the supplied stateid will not  
>>> be the
>>>    current "seqid" as held by the server.  The range of parallelism
>>>    spans from the highest or current "seqid" to a "seqid" value in  
>>> the
>>>    past.  To assist in the discussion, the server's current "seqid"
>>>    value for a layout stateid is defined as:  
>>> SERVER_CURRENT_SEQID.  The
>>>    lowest "seqid" value that is acceptable to the server is  
>>> represented
>>>    by PAST_SEQID.  And the value for the range of valid "seqid"s or
>>>    range of parallelism is VALID_SEQID_RANGE.  Therefore, the  
>>> following
>>>    holds: VALID_SEQID_RANGE = SERVER_CURRENT_SEQID - PAST_SEQID.   
>>> In the
>>>    following, all arithmetic is the modulo arithmetic as described
>>>    above.
>>>
>>>    The server MUST support a minimum VALID_SEQID_RANGE.  The  
>>> minimum is
>>>    defined as: VALID_SEQID_RANGE = summation of 1..N of
>>>    (ca_maxoperations(i) - 1) where N is the number of session fore
>>>    channels and ca_maxoperations is the value returned from
>>>    CREATE_SESSION.  The reason for minus 1 is to allow for the  
>>> required
>>>    SEQUENCE operation.  The server MAY support a VALID_SEQID_RANGE  
>>> value
>>>    larger than the minimum.  The maximum VALID_SEQID_RANGE is (2 ^  
>>> 32 -
>>>    2) (accounts for 0 not being a valid "seqid" value).
>>>
>>>    If the server finds the "seqid" is zero, the NFS4ERR_BAD_STATEID
>>>    error is returned to the client.  The server further validates the
>>>    "seqid" to ensure it is within the range of parallelism,
>>>    VALID_SEQID_RANGE.  If the "seqid" value is outside of that range,
>>>    the error NFS4ERR_OLD_STATEID is returned to the client.  Upon
>>>    receipt of NFS4ERR_OLD_STATEID, the client updates the stateid  
>>> in the
>>>    layout request based on processing of other layout requests and  
>>> re-
>>>    sends the operation to the server.
>>>
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4