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.
> 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...
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
