Linux-NFS Archive mirror
 help / color / mirror / Atom feed

From: Jon Curley <jcurley@purestorage.com>
To: Trond Myklebust <trondmy@kernel.org>
Cc: linux-nfs@vger.kernel.org
Subject: NFS close does not block when server is unavailable
Date: Mon, 6 Apr 2026 08:36:07 -0700	[thread overview]
Message-ID: <CAHeb9+nedZXHXzeCQOo5tJ_kYAYC=sVrzNEtGBACmQKEis4mJA@mail.gmail.com> (raw)

Hi Trond,

We've recently been investigating test failures in our automation
linked to server failures. What we've noticed is that failures during
WRITE do not block close(). Close simply returns success even though
the writes are in a failure loop.

This is easy to reproduce using flexfiles. For example, the flexfile
RFC states that returning EACCES is a mechanism for fencing files. If
you create a server where writes always return that error, commands
like dd will return success while the writes are in a RESET_TO_PNFS
loop.

I'm not trying to get into an O_PONIES argument here but I always
thought NFS close-to-open semantics meant that NFS close makes a
strict effort to flush writes to the server before finishing.

I've been digging into how the NFS client guarantees writes get
flushed. I noticed that nfs/file.c:nfs_file_fsync goes through a much
more rigorous algorithm to flush writes in the face of server
unavailability when compared to nfs/file.c:nfs_file_flush. The
redirtied_pages interlock is especially critical for ensuring
RESET_TO_PNFS events block the syscall from returning.

At first I thought this was intentional. But after looking at the
history, I found this commit:

"NFS: Don't inadvertently clear writeback errors" -
https://github.com/torvalds/linux/commit/aded8d7b54f250af6deb72fde475291cfba513d1

That diff replaced calls to "vfs_fsync" with "nfs_wb_all" in several
places including nfs_file_flush. Since the diff makes no mention of
reducing the guarantees of nfs_file_flush & etc I'm wondering if this
effect was unintentional?

Does it make sense to modify nfs_wb_all to have a loop like
nfs_file_fsync does? Or introduce a new function?

Thanks,
Jon

next             reply	other threads:[~2026-04-06 15:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-06 15:36 Jon Curley [this message]
2026-04-06 20:58 ` NFS close does not block when server is unavailable Trond Myklebust
2026-04-06 22:49   ` Jon Curley

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='CAHeb9+nedZXHXzeCQOo5tJ_kYAYC=sVrzNEtGBACmQKEis4mJA@mail.gmail.com' \
    --to=jcurley@purestorage.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).