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

[Christoph Hellwig <hch@lst.de>]

On Thu, Dec 29, 2016 at 03:54:26PM -0500, Bruce James Fields wrote:
> I assume this would need userspace updates too, so fsck would know not
> to free the unlinked files, and so administrators could see what was
> going on and maybe free them manually if need be.

At least for XFS that's not a worry - if the file system is so toast
that you run xfs_repair NFS exports getting back are the least of your
worries.

Note that these open but unlinked files already happen all the time during
normal operation, they only interesting aspect that NFS would add is that
we might have to reclaim them later when NFS is involved.

> It may seem like overkill, but we have (mostly complete) support for
> running multiple nfsd's in containers, which can be started and stopped
> independently.  And we may want to allow a single filesystem to be
> exported by more than one such nfsd. I think we can still manage that
> with a single unlinked inode list, though--we'd just need logic in nfsd
> to delay freeing as long as any nfsd is restarting.

I'd really want to avoid that logic in the fs.  What I can trivially
offer you from the fs is to:

 1) offer a mount option not to reclaim the unlinked inode list
 2) offer an interface (e.g. in super_operations or export_ops)
    to reclaim the unlinked inodes for a fs mounted with that option

and NFSD would have call the second options.  But I'd like to keep
it out of the fs when that is called exactly.

Note that the filesystem still is in a perfectly fine (although a little
odd) state before we reclaim the unlinked inodes - from the on disk
POV it is not different from a currently active but unlinked file,
the only difference is that we won't ever get a final unlink for it
and only a manual reclaim free them.

The only somewhat hard thing about implementing this on the fs side
is to come up with a scheme to distinguish between old unlinked inodes
left over from before a crash, and new ones created after it that are
active.  But that's something a simple inode flag should be able to
solve.