Re: [nfsv4] parallel LAYOUTGETs using open stateid

[Benny Halevy <[e-mail]>]

On 2010-11-24 00:32, Trond Myklebust wrote:
> On Tue, 2010-11-02 at 00:47 -0400, Fred Isaman wrote:
>> 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.)
> 
> The other point here is that section 18.43.3 explicitly states that 
> 
>         "Once a layout is held on the file by the client, the
>         loga_stateid field MUST be a stateid as returned from a previous
>         LAYOUTGET or LAYOUTRETURN operation or provided by a
>         CB_LAYOUTRECALL operation"
> 
> Leaving aside the issue of why we would even bother allowing the client
> to use a layout stateid as a loga_stateid, if you can just send the open
> stateid and expect the same results; the above text is very explicit. If
> the client thinks it holds a layout, it MUST send the layout stateid. If
> not, the server must clearly be entitled to assume that the client
> believes that it doesn't hold a layout.

That won't hold water if the client is allowed to send multiple such
LAYOUTGETs in parallel.

Benny

> 
> Cheers
>   Trond