[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [nfsv4] layout stateid handling/processing updates



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