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

[Bruce James Fields <bfields@fieldses.org>]

On Mon, Jan 02, 2017 at 10:27:41AM -0500, Bruce James Fields wrote:
> On Mon, Jan 02, 2017 at 09:40:05AM +0100, Christoph Hellwig wrote:
> > On Sun, Jan 01, 2017 at 05:10:25PM -0500, Bruce James Fields wrote:
> > > How do we handle clean shutdown, though?  At a minimum a server admin
> > > needs to be able to e.g. take down the server for an OS upgrade.
> > 
> > That's going to be a nightmare to implement unfortunately.
> 
> Ugh.  I think it's a requirement; without it:
> 
> 	- if we set the flag that allows the client to turn off
> 	  sillyrename, then users will see a regression (ESTALE after
> 	  clean shutdowns in situations we previously guaranteed safe).
> 
> 	- if we don't set that flag, we don't get to turn off client
> 	  sillyrename.  The only improvement is that we avoid ESTALE
> 	  after crashes on files unlinked by a different client than
> 	  held it open.  I don't think that's very interesting on its
> 	  own.

Dumb question: don't local filesystems have the ability to do some sort
of emergency conversion to read-only on detecting corruption?  Does that
prevent any open-file cleanup?  If not that, is there some other
mechanism nfsd could use to crash the filesystem on shutdown if
appropriate (so if it's holding opens on a filesystem and if the
filesystem was mounted with the new option)?

Possibly better would be if we could keep a separate list of
unlinked-but-still-held-by-nfsd files that was managed diferently than
the existing list.

But, I don't have the local filesystem knowledge to know where the
nightmares are here.

--b.