Subject: Re: [nfsv4] layout return - final update ?

From: Benny Halevy <[email-masked]>
Date: Thu, 01 Mar 2012 12:13:24 +0200

On 2012-03-01 05:19, Rick Macklem wrote:
> Trond Myklebust wrote:
>> On Feb 29, 2012, at 6:47 PM, Rick Macklem wrote:
>>
>>> Trond Myklebust wrote:
>>>> On Wed, 2012-02-29 at 15:30 -0500, [email-masked] wrote:
>>>>>> Previously what we discussed was the last CLOSE for the
>>>>>> file/client
>>>>> pair.
>>>>>
>>>>>
>>>>> OK, but the proposed text you supplied is not clear on that point.
>>>>>
>>>>>
>>>>>> That said, I'm not sure about multiple filehandles representing
>>>>>> the
>>>>> same file.
>>>>>
>>>>> Another issue that needs to be clarified in the text.
>>>>
>>>> We should do the same as we do for other state: LAYOUTs for
>>>> different
>>>> filehandles should be represented by different stateids and should
>>>> not
>>>> be combined.
>>>>
>>>> IOW: since you can't choose to CLOSE the file using either
>>>> filehandle,
>>>> but MUST use the filehandle that you received when you did the
>>>> OPEN, I
>>>> suggest that we extend that principle to layouts too.
>>>>
>>> Isn't it also possible to have multiple OPENs for the same FH, but
>>> different open_owner4's?
>>>
>>> (Just fyi, this doesn't affect the FreeBSD
>>> client much, since it holds onto all OPENs for a given FH until all
>>> of the file descriptors are closed and the CLOSEes them all at the
>>> same time. As such, the layout can be returned at that time, if any
>>> case of return_on_closed == true has been received for the layout.)
>>
>> Yes, the fact that you can have several open_owners for the same
>> filehandle does affect the 'last closer' issue. I'm not denying that
>> is a complication, however I believe that the multiple filehandles
>> issue is easily solvable thanks to the precedent that we already have
>> for all the other existing state (open/lock state and delegation
>> state).
>>
> If I understand you, I think we agree. Above you state that different
> FHs have different stateids and shouldn't be combined. To me, that sounds
> like you are saying that the different FHs for the same file shouldn't
> be handled as the same one.
> 
> Did I get that correct? rick

Agreed.

BUT, to the issue at hand, the layout state may transcend OPEN-CLOSE sequence
if return_on_close is set to false.

This means that the client MUST use the layout stateid it has in hand as long as
it keeps this state, even if it CLOSEd the filehandle and reOPENed it.
Otherwise, if it sends a LAYOUTGET using the new open_stateid, it will
implicitly return its previous layout state, as per our forgetful client
model and the semantics discussed for LAYOUTGET using non-layout stateid.

Given that, the new open stateid(s) will be re-associated with the old layout
stateid on the server and the respective CLOSE(s) after return_on_close
will invalidate the whole layout state for that client:filehandle.

Benny

> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Fri, 2 Mar 2012 08:52:55 -0500

> model and the semantics discussed for LAYOUTGET using non-layout stateid.

Good catch.

Is this going to be an issue for existing clients, who might not be expecting 
this to happen, given that RFC5661 didn't say this explicitly?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benny Halevy
Sent: Thursday, March 01, 2012 5:13 AM
To: Rick Macklem
Cc: Trond Myklebust; eshel; nfsv4
Subject: Re: [nfsv4] layout return - final update ?

Agreed.

Benny

---

From: Benny Halevy <[email-masked]>
Date: Sun, 04 Mar 2012 09:19:39 +0200

> this to happen, given that RFC5661 didn't say this explicitly?

The errata might be clarifying RFC5661, based on the following text.
Existing clients should expect this behavior anyway, the gist of the errata
is about serializing the LAYOUTGETs wityh non-layout stateid, no their
expected semantics.

12.5.2.  Getting a Layout
   In order to get a layout, the client must first have opened the file
   via the OPEN operation.  When a client has no layout on a file, it
   MUST present an open stateid, a delegation stateid, or a byte-range
   lock stateid in the loga_stateid argument.  A successful LAYOUTGET
   result includes a layout stateid.  The first successful LAYOUTGET
   processed by the server using a non-layout stateid as an argument
   MUST have the "seqid" field of the layout stateid in the response set
   to one.  Thereafter, the client MUST use a layout stateid (see
   Section 12.5.3) on future invocations of LAYOUTGET on the file, and
   the "seqid" MUST NOT be set to zero.  Once the layout has been
   retrieved, it can be held across multiple OPEN and CLOSE sequences.
   Therefore, a client may hold a layout for a file that is not
   currently open by any user on the client.  This allows for the
   caching of layouts beyond CLOSE.