headers
Marc Eshel | 1 Mar 2012 01:25
Picon
Favicon

Re: layout return - final update ?

Lets try to keep it simple. Can we agree that once the server returns a 
layout with return_on_closed == true for a file A (what ever way it is 
represented) to client B the serve will be allowed to invalidate the 
layouts on the last close  of file A by client B. If you disagree please 
propose a clear and complete alternative.
Marc.

From:
Rick Macklem <rmacklem <at> uoguelph.ca>
To:
Trond Myklebust <Trond.Myklebust <at> netapp.com>
Cc:
eshel <at> almaden.ibm.com, nfsv4 <at> ietf.org, david noveck <david.noveck <at> emc.com>
Date:
02/29/2012 03:48 PM
Subject:
Re: [nfsv4] layout return - final update ?

Trond Myklebust wrote:
> On Wed, 2012-02-29 at 15:30 -0500, david.noveck <at> emc.com 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rick Macklem | 1 Mar 2012 01:53
Picon
Favicon

Re: layout return - final update ?

Marc Eshel wrote:
> Lets try to keep it simple. Can we agree that once the server returns
> a
> layout with return_on_closed == true for a file A

> (what ever way it is represented)
If, by "what ever way it is represented" you mean a file
handle, then that sounds fine to me.

If you mean "any file with the same fileid and fsid from
the same server", I'm not so sure, since it would be difficult
to find all cases of this, imho. Yes, fileid and fsid are attributes,
but a client tends to cache them (with no guarantee that
they are up-to-date) and even an exhaustive search of the attribute
cache might not find them all. (I believe this is only an issue for
cases where a file has multiple FH's, possibly after a RENAME
against certains servers?)

rick

> to client B the serve will be allowed to invalidate the
> layouts on the last close of file A by client B. If you disagree
> please
> propose a clear and complete alternative.
> Marc.
> 
> 
> 
> From:
> Rick Macklem <rmacklem <at> uoguelph.ca>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Marc Eshel | 1 Mar 2012 02:37
Picon
Favicon

Re: layout return - final update ?

nfsv4-bounces <at> ietf.org wrote on 02/29/2012 04:53:47 PM:
> 
> Trond Myklebust, nfsv4
> 
> Marc Eshel wrote:
> > Lets try to keep it simple. Can we agree that once the server returns
> > a
> > layout with return_on_closed == true for a file A
> 
> > (what ever way it is represented)
> If, by "what ever way it is represented" you mean a file
> handle, then that sounds fine to me.

Yes, any fh that maps to the same file (inode). btw, files might also have 
different fh becuse of hard links not just rename.

> 
> If you mean "any file with the same fileid and fsid from
> the same server", I'm not so sure, since it would be difficult
> to find all cases of this, imho. Yes, fileid and fsid are attributes,
> but a client tends to cache them (with no guarantee that
> they are up-to-date) and even an exhaustive search of the attribute
> cache might not find them all. (I believe this is only an issue for
> cases where a file has multiple FH's, possibly after a RENAME
> against certains servers?)
> 
> rick
> 
> > to client B the serve will be allowed to invalidate the
> > layouts on the last close of file A by client B. If you disagree
(Continue reading)

Permalink | Reply | 2 comments |
headers
Myklebust, Trond | 1 Mar 2012 04:15
Picon

Re: layout return - final update ?


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 <at> emc.com 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?
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rick Macklem | 1 Mar 2012 04:16
Picon
Favicon

Re: layout return - final update ?

Marc Eshel wrote:
> nfsv4-bounces <at> ietf.org wrote on 02/29/2012 04:53:47 PM:
> >
> > Trond Myklebust, nfsv4
> >
> > Marc Eshel wrote:
> > > Lets try to keep it simple. Can we agree that once the server
> > > returns
> > > a
> > > layout with return_on_closed == true for a file A
> >
> > > (what ever way it is represented)
> > If, by "what ever way it is represented" you mean a file
> > handle, then that sounds fine to me.
> 
> Yes, any fh that maps to the same file (inode). btw, files might also
> have
> different fh becuse of hard links not just rename.
> 
Well, I think this is too hard for a client to handle. (ie.
Recognizing that multiple FH's are for the same file.)

When I said FH, I meant that the rule would apply to one FH,
not all FHs that map to the same file.

rick

> >
> > If you mean "any file with the same fileid and fsid from
> > the same server", I'm not so sure, since it would be difficult
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rick Macklem | 1 Mar 2012 04:19
Picon
Favicon

Re: layout return - final update ?

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 <at> emc.com 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.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Myklebust, Trond | 1 Mar 2012 04:51
Picon

Re: layout return - final update ?

ACK. :-)

Rick Macklem <rmacklem <at> uoguelph.ca> 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 <at> emc.com 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benny Halevy | 1 Mar 2012 06:01

Re: layout return - final update ?

On 2012-02-29 22:30, david.noveck <at> emc.com 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marc Eshel | 1 Mar 2012 06:59
Picon
Favicon

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 <at> tonian.com>
To:
david.noveck <at> emc.com
Cc:
eshel <at> almaden.ibm.com, nfsv4 <at> ietf.org
Date:
02/29/2012 09:01 PM
Subject:
Re: [nfsv4] layout return - final update ?
Sent by:
nfsv4-bounces <at> ietf.org

On 2012-02-29 22:30, david.noveck <at> emc.com 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.
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benny Halevy | 1 Mar 2012 11:03

Re: layout return - final update ?

On 2012-03-01 05:16, Rick Macklem wrote:
> Marc Eshel wrote:
>> nfsv4-bounces <at> ietf.org wrote on 02/29/2012 04:53:47 PM:
>>>
>>> Trond Myklebust, nfsv4
>>>
>>> Marc Eshel wrote:
>>>> Lets try to keep it simple. Can we agree that once the server
>>>> returns
>>>> a
>>>> layout with return_on_closed == true for a file A
>>>
>>>> (what ever way it is represented)
>>> If, by "what ever way it is represented" you mean a file
>>> handle, then that sounds fine to me.
>>
>> Yes, any fh that maps to the same file (inode). btw, files might also
>> have
>> different fh becuse of hard links not just rename.
>>
> Well, I think this is too hard for a client to handle. (ie.
> Recognizing that multiple FH's are for the same file.)
> 
> When I said FH, I meant that the rule would apply to one FH,
> not all FHs that map to the same file.

Agreed.  The layout state is tied to a particular filehandle using
which the client sends LAYOUTGET, LAYOUTCOMMIT, LAYOUTRETURN, and
it is the same filehnadle referred by CB_LAYOUTRECALL via lor_fh.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane