Subject: Re: [nfsv4] parallel LAYOUTGETs using open stateid

From: Fred Isaman <[email-masked]>
Date: Tue, 2 Nov 2010 00:47:42 -0400

On Thu, Oct 7, 2010 at 10:18 AM, Benny Halevy <[email-masked]> wrote:
> On 2010-10-07 09:50, Benny Halevy wrote:
>> On Thu, Oct 7, 2010 at 9:21 AM, Fred Isaman <[email-masked]> 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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 23 Nov 2010 17:32:13 -0500

> currently valid response (which would be the one the server processed

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.

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Benny Halevy <[email-masked]>
Date: Thu, 25 Nov 2010 00:33:23 +0200

> 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