Re: [nfsv4] parallel LAYOUTGETs using open stateid

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
:)

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