Re: [nfsv4] RFC 7530: Filehandle of opened file after the REMOVE

[David Noveck <[e-mail]>]

> We could still persist that information
> somewhere, or use a flag to delay the deletion of unlinked inodes until
> NFSD runs.

You need to delay the deletion until after the grace period is over.  There
may be technical issues with this but the biggest hurdle may may be
architectural/political.  I expect that people involved in file system
recovery may have trouble with the idea that the NFS server is telling them
when they can and cannot do various pieces of file system recovery.

It might be more possible to ask them to complete recovery but move the
unlinked inodes to a directory like /unlinked-inodes and consider the
recovery complete before NFS actually runs.  If that is OK, and I believe
it is, the result would be almost the same as the NFS server moving the
file to that directory in the first place, using a server-based silly
rename.

> Personally I'd love to see sillyrename die.

I think you really want to see it dead.  Actually watching it die is
boring, sort of like watching paint dry

> It's a major pain for getting sensible semantics out of NFS.

Please elaborate.  Would a server-based silly rename allow the sensible
semantics you are looking for?

The best way to get silly rename to die is to provide an alternative, and I
believe an extension to NFSv4.2 could be defined to provide that.

> The unlinked inode list is almost a directory, except that it doesn't
> have names for the entries, you can only find inodes on it by the inode
> number and generation (aka NFS file handle).

The existence of those names could be considered a flaw, but if we define
an extension to allow silly rename to be eliminated, we should not REQUIRE
or RECOMMEND they they not be visible.  I'm thinking of some non-RFC2119
characterization such as "It is most desirable that these objects not be
accessible other than though  use of their file handles".

Btw, my preferred title for such a document, almost certain to be rejected,
is "Silly Rename Must Die" :-)


On Thu, Dec 29, 2016 at 2:48 AM, Christoph Hellwig <[e-mail]> wrote:

> On Wed, Dec 28, 2016 at 09:47:03PM -0500, Bruce James Fields wrote:
> > I never seriously worked on it, but for a while I was in the habit of
> > running it by people.  Christoph Hellwig thought it was doable (I think
> > he suggested some sort of callback from the filesystem during the
> > garbage collection, possibly because he had in mind some other
> > application for that--but my memory may be wrong).  Chris Mason didn't
> > like the idea at all.  He asked what we expect to happen on fsck, or if
> > the filesystem gets mounted without nfs getting started, or... some
> > other scenarios I forget.
>
> The way open but unlinked files are handled by modern transaction
> file systems is that the file system has a list of those inodes
> (in XFS this is the unlinked inode list in the allocation group header,
> other file systems use different terminologies and slightly different
> technics, e.g. in ext4 the list is global for the whole file system).
>
> After an unclean shutdown when file system recovery is run we'll perform
> the deferred delete for all the inodes on the unlinked inode list.
> At that point the file system could in theory inform NFSD about that
> fact.  But at least as far as the current Linux kernel is concerned (
> sorry for delving into implementation details, but I guess this is still
> easier to understand than an abstract discussion) at the point where
> file system performs recovery NFSD has not been started, or at least
> doesn't
> know about the file system yet.   We could still persist that information
> somewhere, or use a flag to delay the deletion of unlinked inodes until
> NFSD runs.
>
> > We could do the same silly rename tricks on the server side.  Something
> > like: create a directory with an unlikely name in the root of the
> > export, rename files there on REMOVE.  Possible problems:
>
> Personally I'd love to see sillyrename die.  It's a major pain for
> getting sensible semantics out of NFS.
>
> >       - you'll never be able to completely hide that directory.  But
> >         maybe we could get some sort of filesystem support for a
> >         hidden directory.
>
>
> The unlinked inode list is almost a directory, except that it doesn't
> have names for the entries, you can only find inodes on it by the inode
> number and generation (aka NFS file handle).
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>