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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
