Re: layout return - final update ?

From my server point of view either options are fine I am just trying to
make as many of you happy which is very tricky. So let me try again. What
I think most people agree on is the last statement by Benny. Given that
all layout operations, as well as CLOSE, are done on a fh we can safely
refer to the fh as representing the file. So all the rules regarding
return-on-close refer to (fh, client).
If I don't hear more objection I will try to write it into the text and
probably trigger some other issue :)
Marc.



From:
Benny Halevy <bhalevy@...>
To:
david.noveck@...
Cc:
eshel@..., nfsv4@...
Date:
02/29/2012 09:01 PM
Subject:
Re: [nfsv4] layout return - final update ?
Sent by:
nfsv4-bounces@...



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 _______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4




_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4