From: trondmy@kernel.org
To: linux-nfs@vger.kernel.org
Cc: Jeff Layton <jlayton@kernel.org>, Josef Bacik <josef@toxicpanda.com>
Subject: [PATCH RFC 0/4] Containerised NFS clients and teardown
Date: Thu, 20 Mar 2025 13:44:36 -0400 [thread overview]
Message-ID: <cover.1742490771.git.trond.myklebust@hammerspace.com> (raw)
From: Trond Myklebust <trond.myklebust@hammerspace.com>
When a NFS client is started from inside a container, it is often not
possible to ensure a safe shutdown and flush of the data before the
container orchestrator steps in to tear down the network. Typically,
what can happen is that the orchestrator triggers a lazy umount of the
mounted filesystems, then proceeds to delete virtual network device
links, bridges, NAT configurations, etc.
Once that happens, it may be impossible to reach into the container to
perform any further shutdown actions on the NFS client.
This patchset proposes to allow the client to deal with these situations
by treating the two errors ENETDOWN and ENETUNREACH as being fatal.
The intention is to then allow the I/O queue to drain, and any remaining
RPC calls to error out, so that the lazy umounts can complete the
shutdown process.
In order to do so, a new mount option "fatal_errors" is introduced,
which can take the values "default", "none" and "enetdown:enetunreach".
The value "none" forces the existing behaviour, whereby hard mounts are
unaffected by the ENETDOWN and ENETUNREACH errors.
The value "enetdown:enetunreach" forces ENETDOWN and ENETUNREACH errors
to always be fatal.
If the user does not specify the "fatal_errors" option, or uses the
value "default", then ENETDOWN and ENETUNREACH will be fatal if the
mount was started from inside a network namespace that is not
"init_net", and otherwise not.
The expectation is that users will normally not need to set this option,
unless they are running inside a container, and want to prevent ENETDOWN
and ENETUNREACH from being fatal by setting "-ofatal_errors=none".
Trond Myklebust (4):
NFS: Add a mount option to make ENETUNREACH errors fatal
NFS: Treat ENETUNREACH errors as fatal in containers
pNFS/flexfiles: Treat ENETUNREACH errors as fatal in containers
pNFS/flexfiles: Report ENETDOWN as a connection error
fs/nfs/client.c | 5 ++++
fs/nfs/flexfilelayout/flexfilelayout.c | 24 ++++++++++++++--
fs/nfs/fs_context.c | 38 ++++++++++++++++++++++++++
fs/nfs/nfs3client.c | 2 ++
fs/nfs/nfs4client.c | 5 ++++
fs/nfs/nfs4proc.c | 3 ++
fs/nfs/super.c | 2 ++
include/linux/nfs4.h | 1 +
include/linux/nfs_fs_sb.h | 2 ++
include/linux/sunrpc/clnt.h | 5 +++-
include/linux/sunrpc/sched.h | 1 +
net/sunrpc/clnt.c | 30 ++++++++++++++------
12 files changed, 107 insertions(+), 11 deletions(-)
--
2.48.1
next reply other threads:[~2025-03-20 17:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 17:44 trondmy [this message]
2025-03-20 17:44 ` [PATCH RFC 1/4] NFS: Add a mount option to make ENETUNREACH errors fatal trondmy
2025-03-20 17:44 ` [PATCH RFC 2/4] NFS: Treat ENETUNREACH errors as fatal in containers trondmy
2025-03-20 17:44 ` [PATCH RFC 3/4] pNFS/flexfiles: " trondmy
2025-03-20 17:44 ` [PATCH RFC 4/4] pNFS/flexfiles: Report ENETDOWN as a connection error trondmy
2025-03-20 19:32 ` [PATCH RFC 0/4] Containerised NFS clients and teardown Jeff Layton
2025-03-20 20:40 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1742490771.git.trond.myklebust@hammerspace.com \
--to=trondmy@kernel.org \
--cc=jlayton@kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox