On Tue, 2025-03-25 at 20:40 +0100, Lionel Cons wrote: > On Tue, 25 Mar 2025 at 17:19, <trondmy@xxxxxxxxxx> wrote: > > > > From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > > > > With the recent patch series that caused containerised mounts which > > return ENETUNREACH or ENETDOWN errors to report fatal errors, we > > also > > want to ensure that the state manager thread also triggers fatal > > errors > > in the processes or threads that are waiting for recovery to > > complete. > > > > --- > > v2: > > - Return EIO instead of ENETUNREACH in nfs4_wait_clnt_recover() > > > > Trond Myklebust (4): > > SUNRPC: rpcbind should never reset the port to the value '0' > > SUNRPC: rpc_clnt_set_transport() must not change the autobind > > setting > > NFSv4: clp->cl_cons_state < 0 signifies an invalid nfs_client > > NFSv4: Treat ENETUNREACH errors as fatal for state recovery > > > > fs/nfs/nfs4state.c | 14 +++++++++++--- > > net/sunrpc/clnt.c | 3 --- > > net/sunrpc/rpcb_clnt.c | 5 +++-- > > 3 files changed, 14 insertions(+), 8 deletions(-) > > 1. Can this "ENETUNREACH or ENETDOWN are fatal" feature be turned > off? > > 2. We have concerns about this feature - what will happen if a switch > or router gets rebooted? What will happen if you unplug your laptop? > What will happen if you enable/disable your VPN software on a machine > or container? What will happen if you switch WIFIs on your laptop? > > All these scenarios will trigger a temporary ENETUNREACH or ENETDOWN, > and should NOT be fatal for mounts or containers. TL;DR: Yes, you can turn it off using a mount option, but we preserve the existing hard mount behaviour unless you are actually mounting in a container. See the description in the first series of patches: https://lore.kernel.org/linux-nfs/2a37ba5a-f212-4456-a7c1-3f96b1148b3b@xxxxxxxxxx/T/#mf3df4516c5fcb0ef22c1c1c6f5433535f4d4805a -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
