Re: [RFC v3 0/7] NFS Force Unmounting

[Joshua Watt <jpewhacker@gmail.com>]

On Wed, 2017-11-15 at 13:40 +0000, Trond Myklebust wrote:
> On Tue, 2017-11-14 at 17:06 -0600, Joshua Watt wrote:
> > After some additional testing on version 2, I realized that 1) my
> > test
> > setup was bad (Doh!) and 2) using remount isn't really an ideal
> > method
> > for setting the "serverfailed" mount flag. The reason being that
> > any
> > userspace remount is going to touch the file system and probably
> > invoke
> > some RPCs for inode validation as such. If the server is truly
> > dead,
> > these RPCs will have to time out before the flag could actually be
> > set.
> > This not only takes a long time, but will probably also fail,
> > causing
> > the remount to fail and not set the flag, defeating the purpose.
> 
> Why? There should be no reason to have to revalidate the path in
> order
> to change mount options on a mount point.

I figured this out... the revalidation is not required for the mount(2)
syscall when remounting. However, libmount tries to do a few file
system checks that do required validation. You can convince it to skip
these checks like so:

 mount -c 172.16.9.0:/ /tmp/nfsmount -o remount,serverfailed

The "-c" prevents canonicalizing the mount path (meaning you must
provide the canonical path on the command line), and you have to
specify the "block device" (e.g. "172.16.9.0:/") to prevent it doing
some fstatat() checks on the mount path while parsing through mtab.

It's annoying you can't do the easier:

 mount /tmp/nfsmount -o remount,serverfailed

but that's not the kernels fault.

> 
> > This patch set works around this by exposing the failed server flag
> > in
> > debugfs. In addition, the flag now applies at the nfs_client level
> > (instead of the nfs_server). Setting the flag will cancel all RPCs
> > in
> > the client, as well as all nfs_servers attached to it. This ensures
> > that
> > you get all the mounts, even when dealing with submounts that cross
> > remote device boundaries. This is also where the nosharecache
> > option
> > applying to nfs_clients becomes useful... it will prevent sharing
> > between other explicit mount calls, but submounts will all still
> > share a
> > nfs_client (and fail together).
> > 
> > Obviously, debugfs is not a permanent solution for this, so some
> > discussion needs to be had on how this will be administered "in the
> > real
> > world" (I think "remount" is off the table).
> > 
> 
> We're not adding any APIs to debugfs. That's a deal breaker...

Sure. Is the mount option still the best way forward then, or are there
other options to be explored?

> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer, PrimaryData
> trond.myklebust@primarydata.com