|
»
« Return to Thread: layout return - final update ?
Re: layout return - final update ?
by Rick Macklem
::
Rate this Message:
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@...>
> To:
> Trond Myklebust <Trond.Myklebust@...>
> Cc:
> eshel@..., nfsv4@..., david noveck
> <david.noveck@...>
> 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@... 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.)
>
> rick
>
> > > > 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.
> >
> >
> > --
> > Trond Myklebust
> > Linux NFS client maintainer
> >
> > NetApp
> > Trond.Myklebust@...
> > www.netapp.com
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@...
> > https://www.ietf.org/mailman/listinfo/nfsv4_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4
> 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@...>
> To:
> Trond Myklebust <Trond.Myklebust@...>
> Cc:
> eshel@..., nfsv4@..., david noveck
> <david.noveck@...>
> 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@... 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.)
>
> rick
>
> > > > 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.
> >
> >
> > --
> > Trond Myklebust
> > Linux NFS client maintainer
> >
> > NetApp
> > Trond.Myklebust@...
> > www.netapp.com
> >
> > _______________________________________________
> > 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 |
