|
»
« Return to Thread: layout return - final update ?
Re: layout return - final update ?
by Benny Halevy-4
::
Rate this Message:
On 2012-02-29 22:30, 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.
>
Yeah. Sorry for bringing that up ;-)
Anyhow, given that all layout operations, as well as CLOSE, are done on a filehandle
we can safely refer to the filehandle as representing the file. Different filehandle
may represent the same inode (fsid:fileid) on the server but they'll be associated
with separate layout states.
> *> This approach seems valid but it complicates the case of layouts not marked as return_on_close that survived a previous last CLOSE as these will not be affected now.*
>
> If we are talking about layout not marked return-on-close that were sent before the first return-on-close layout, then I think that the text you proposed is exactly the same in this respect. Or am I missing something here?
>
>
> *> Since we are talking about losing the layout on the last CLOSE from the client of that file a catch all approach would be simpler.*
>
> I'm not sure that that is so. First of all, it is very natural/required for clients and servers to have data structures representing open files, and linking return-on-close layout to these seems relatively straightforward. on the other hand, I would not expect clients and servers to always have an infrastructure to keep track of client/fh or client/file pairs and thus always be able to see when a last close is being done. To top it all off, you may have racing closes so last-close-at-issue may not be the same as last-close-at-receipt. Also closes and opens can race. Those sorts of considerations led to me thinking associating a layout with a specific open file was simpler or at least it made my head hurt less.
The root problem is that the layout stateid is not tied to any specific open stateid.
We require the client to first OPEN the filehandle to get the first layout stateid but from then on
the layout stateid is independent and layout operations affect it regardless of any OPENs and CLOSEs
on that filehandle.
Benny
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--
> *From:* Benny Halevy [mailto:bhalevy@...]
> *Sent:* Wednesday, February 29, 2012 2:07 PM
> *To:* Noveck, David
> *Cc:* eshel@...; nfsv4@...
> *Subject:* Re: [nfsv4] layout return - final update ?
>
>
> On Feb 29, 2012 1:47 AM, <david.noveck@... <mailto:david.noveck@...>> wrote:
>>
>> The last few sentences seem to be written assuming that that three will be only one
>> open file per fh/client pair. It seem that it says that if owner A opens a file and
>> Gets some layouts, then of owner B opens the same file then all the layout he gets should be
>> marked logr_return_on_close. Is that what is intended?
>
> I believe so.
>
> And if so, when should
>> these be invalidated. On the first close, which the text seems to suggest?
>
> Previously what we discussed was the last CLOSE for the file/client pair.
> That said, I'm not sure about multiple filehandles representing the same file.
>
> I think the
>> right direction, not having thought about it terribly much, is that logr_return_on_close
>> layouts are open-file-associated and if that is something that you can agree with, you
>> would b better off if the text said that explicitly.
>
> This approach seems valid but it complicates the case of layouts not marked as return_on_close that survived a previous last CLOSE as these will not be affected now.
> Since we are talking about losing the layout on the last CLOSE from the client of that file a catch all approach would be simpler.
>
> Benny
>
>>
>> -----Original Message-----
>> From: nfsv4-bounces@... <mailto:nfsv4-bounces@...> [mailto:nfsv4-bounces@... <mailto:nfsv4-bounces@...>] On Behalf Of Marc Eshel
>> Sent: Tuesday, February 28, 2012 4:39 PM
>> To: NFSv4
>> Subject: [nfsv4] layout return - final update ?
>>
>> Hopefully the final correction to the logr_return_on_close result field in
>>
>>
>> 18.43.3 that should go into v4.1 errata.
>> Marc.
>>
>> section 18.43.3 say:
>>
>> The logr_return_on_close result field is a directive to return the layout
>> before closing the file. When the metadata server sets this return value
>> to TRUE, it MUST be prepared to recall the layout in the case in which the
>> client fails to return the layout before close. For the metadata server
>> that knows a layout must be returned before a close of the file, this
>> return value can be used to communicate the desired behavior to the client
>> and thus remove one extra step from the client's and metadata server's
>> interaction.
>>
>> it should say:
>>
>> The logr_return_on_close result field is a directive to return or forget
>> the layout before closing the file . When the metadata server sets this
>> return value to TRUE, the client MUST NOT use the layout after sending
>> the last CLOSE of that file. Any outstanding COMMIT to the data servers
>> or LAYOUTCOMMIT to the metadata server MUST be sent prior to closing the
>> file. This return value is used to communicate to the client that any
>> layout or segment of a layout that were given with logr_return_on_close
>> set to TRUE will result in the server invalidating all layouts of
>> layouttype4 of loga_layout_type for the file after it was closed. Once
>> the server returns logr_return_on_close set to TRUE to a client for a
>> given file it MUST set logr_return_on_close to TRUE for all subsequent
>> layouts or segments of layoutype4 of the respective loga_layout_type for
>> that file and client until that file is closed.
>>
>> Notes:
>>
>> This directive will remove one or more extra steps from the client's and
>> metadata server's interaction.
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@... <mailto:nfsv4@...>
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@... <mailto:nfsv4@...>
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@... <mailto: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
> *> 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.
>
Yeah. Sorry for bringing that up ;-)
Anyhow, given that all layout operations, as well as CLOSE, are done on a filehandle
we can safely refer to the filehandle as representing the file. Different filehandle
may represent the same inode (fsid:fileid) on the server but they'll be associated
with separate layout states.
> *> This approach seems valid but it complicates the case of layouts not marked as return_on_close that survived a previous last CLOSE as these will not be affected now.*
>
> If we are talking about layout not marked return-on-close that were sent before the first return-on-close layout, then I think that the text you proposed is exactly the same in this respect. Or am I missing something here?
>
>
> *> Since we are talking about losing the layout on the last CLOSE from the client of that file a catch all approach would be simpler.*
>
> I'm not sure that that is so. First of all, it is very natural/required for clients and servers to have data structures representing open files, and linking return-on-close layout to these seems relatively straightforward. on the other hand, I would not expect clients and servers to always have an infrastructure to keep track of client/fh or client/file pairs and thus always be able to see when a last close is being done. To top it all off, you may have racing closes so last-close-at-issue may not be the same as last-close-at-receipt. Also closes and opens can race. Those sorts of considerations led to me thinking associating a layout with a specific open file was simpler or at least it made my head hurt less.
The root problem is that the layout stateid is not tied to any specific open stateid.
We require the client to first OPEN the filehandle to get the first layout stateid but from then on
the layout stateid is independent and layout operations affect it regardless of any OPENs and CLOSEs
on that filehandle.
Benny
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--
> *From:* Benny Halevy [mailto:bhalevy@...]
> *Sent:* Wednesday, February 29, 2012 2:07 PM
> *To:* Noveck, David
> *Cc:* eshel@...; nfsv4@...
> *Subject:* Re: [nfsv4] layout return - final update ?
>
>
> On Feb 29, 2012 1:47 AM, <david.noveck@... <mailto:david.noveck@...>> wrote:
>>
>> The last few sentences seem to be written assuming that that three will be only one
>> open file per fh/client pair. It seem that it says that if owner A opens a file and
>> Gets some layouts, then of owner B opens the same file then all the layout he gets should be
>> marked logr_return_on_close. Is that what is intended?
>
> I believe so.
>
> And if so, when should
>> these be invalidated. On the first close, which the text seems to suggest?
>
> Previously what we discussed was the last CLOSE for the file/client pair.
> That said, I'm not sure about multiple filehandles representing the same file.
>
> I think the
>> right direction, not having thought about it terribly much, is that logr_return_on_close
>> layouts are open-file-associated and if that is something that you can agree with, you
>> would b better off if the text said that explicitly.
>
> This approach seems valid but it complicates the case of layouts not marked as return_on_close that survived a previous last CLOSE as these will not be affected now.
> Since we are talking about losing the layout on the last CLOSE from the client of that file a catch all approach would be simpler.
>
> Benny
>
>>
>> -----Original Message-----
>> From: nfsv4-bounces@... <mailto:nfsv4-bounces@...> [mailto:nfsv4-bounces@... <mailto:nfsv4-bounces@...>] On Behalf Of Marc Eshel
>> Sent: Tuesday, February 28, 2012 4:39 PM
>> To: NFSv4
>> Subject: [nfsv4] layout return - final update ?
>>
>> Hopefully the final correction to the logr_return_on_close result field in
>>
>>
>> 18.43.3 that should go into v4.1 errata.
>> Marc.
>>
>> section 18.43.3 say:
>>
>> The logr_return_on_close result field is a directive to return the layout
>> before closing the file. When the metadata server sets this return value
>> to TRUE, it MUST be prepared to recall the layout in the case in which the
>> client fails to return the layout before close. For the metadata server
>> that knows a layout must be returned before a close of the file, this
>> return value can be used to communicate the desired behavior to the client
>> and thus remove one extra step from the client's and metadata server's
>> interaction.
>>
>> it should say:
>>
>> The logr_return_on_close result field is a directive to return or forget
>> the layout before closing the file . When the metadata server sets this
>> return value to TRUE, the client MUST NOT use the layout after sending
>> the last CLOSE of that file. Any outstanding COMMIT to the data servers
>> or LAYOUTCOMMIT to the metadata server MUST be sent prior to closing the
>> file. This return value is used to communicate to the client that any
>> layout or segment of a layout that were given with logr_return_on_close
>> set to TRUE will result in the server invalidating all layouts of
>> layouttype4 of loga_layout_type for the file after it was closed. Once
>> the server returns logr_return_on_close set to TRUE to a client for a
>> given file it MUST set logr_return_on_close to TRUE for all subsequent
>> layouts or segments of layoutype4 of the respective loga_layout_type for
>> that file and client until that file is closed.
>>
>> Notes:
>>
>> This directive will remove one or more extra steps from the client's and
>> metadata server's interaction.
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@... <mailto:nfsv4@...>
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@... <mailto:nfsv4@...>
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@... <mailto: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 |
