|
»
« Return to Thread: layout return - final update ?
Re: layout return - final update ?
by david.noveck
::
Rate this Message:
> 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.
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: nfsv4-bounces@... [mailto:nfsv4-bounces@...] 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 ?
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, david.noveck@... 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
> nfsv4@...
> https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4
> 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.
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: nfsv4-bounces@... [mailto:nfsv4-bounces@...] 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 ?
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, david.noveck@... 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
> nfsv4@...
> https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4
« Return to Thread: layout return - final update ?
| Free embeddable forum powered by Nabble | Forum Help |
