Re: [nfsv4] parallel LAYOUTGETs using open stateid

[Fred Isaman <[e-mail]>]

On Thu, Oct 7, 2010 at 10:18 AM, Benny Halevy <[e-mail]> wrote:
> On 2010-10-07 09:50, Benny Halevy wrote:
>> On Thu, Oct 7, 2010 at 9:21 AM, Fred Isaman <[e-mail]> 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).
>
> Just to clarify, what matters in this case is the returned logr_stateid
> and seqid while the sent loga_stateid does not matter much.
> If there's a pending layout recall on the server which has not been
> completed by a matching LAYOUTRETURN the server can safely assume
> that the layoutget was sent before the client received the CB_LAYOUTRECALL
> and return NFS4ERR_RECALLCONFLICT.
>
> Benny
>
>> Are there any problems you see in that approach?
>>
>> Benny

After giving this more thought, I have decided that, because of the
forgetful model, the spec gives the server no choice when responding
to a LAYOUTGET(openstateid) but to assume that the client has
forgotten all previous layouts, so it must hand out a new stateid.
Which means that the client MUST serialize any openstate LAYOUTGETs,
since otherwise it has no means to determine which order the server
processed them, which means it can't tell which is the single
currently valid response (which would be the one the server processed
last.)

Fred