Re: [nfsv4] parallel LAYOUTGETs using open stateid

On 2010-10-07 11:32, William A. (Andy) Adamson wrote:
> On Thu, Oct 7, 2010 at 10:36 AM, Benny Halevy <bhalevy@panasas.com> wrote:
>> On 2010-10-07 10:20, Fred Isaman wrote:
>>> On Thu, Oct 7, 2010 at 9:50 AM, Benny Halevy <bhalevy@panasas.com> wrote:
>>>> On Thu, Oct 7, 2010 at 9:21 AM, Fred Isaman <iisaman@citi.umich.edu> wrote:
>>>>> This question came up as I was going through our layout stateid code.
>>>>>
>>>>> Can the client send multiple LAYOUTGETs in parallel before getting a
>>>>> layoutstateid by using an open stateid?
>>>>> If so, what is the server response?  The spec is not clear, but I
>>>>> would assume it would do one of:
>>>>> a) returning an error (what error?) on all but the first LAYOUTGET it sees
>>>>> b) matching the openstateid to the layoutstateid it has already given
>>>>> out and sending a reply with that stateid and a bumped seqid
>>>>
>>>> I'm in favour of (b).
>>>> Are there any problems you see in that approach?
>>>>
>>>> Benny
>>>>
>>>
>>> The wrinkle it adds is that, in the normal case, after the CB_RECALL
>>> is resolved, any stale LAYOUTGETs (sent by the client before it
>>> received the CB_RECALL) that the server receives will either be
>>> processed normally with a bumped seqid or an error (if the server
>>
>> But the client MUST not process the layout recall before receiving
>> replies for the outstanding layoutgets. (see section 12.5.5.2.1.
>> Layout Recall and Return Sequencing)
> 
> Hmmm. But 12.5.5.2.1 is referring to outstanding layoutget's with the
> same stateid as the cb_layoutrecall. If the server creates "new" ones
> as described below by Fred, the client doesn't need to wait. Of
> course, the client has no way of knowing until it get's the response
> :)

The spec describes that situation as:
   the "seqid" is not exactly one higher than what
   the client currently has recorded.

With the initial open/deleg/lock stated, the "other" part
of the stateid is different - therefore one can assume
the seqid if not exactly one higher than ... so I think that the
client MUST wait as described in the is section.

Though, I agree the can be improved and clarified.
In particular:
   The client MUST wait before
   processing such a CB_LAYOUTRECALL until it processes all replies for
   outstanding LAYOUTGET and LAYOUTRETURN operations for the
   corresponding file with seqid less than the seqid given by
   CB_LAYOUTRECALL (lor_stateid; see Section 20.3.)

should explicitly cover outstanding LAYOUTGETs with non-layout stateid.

Benny

> 
> -->Andy
>>
>> Benny
>>
>>> invalidated the "other" part of the stateid.)  In the openstateid
>>> case, the server loses the option of returning an error, instead it
>>> wuold create a new "other" with seqid=1.  That said, I don't see that
>>> this causes any problems apart from extra bookkeeping.
>>>
>>> Fred
>>>
>>>>> Fred
>>>>> _______________________________________________
>>>>> nfsv4 mailing list
>>>>> nfsv4@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>>>
>>>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>