« Return to Thread: layout return - final update ?

Re: layout return - final update ?

by Marc Eshel :: Rate this Message:

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@...>
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 ?