summaryrefslogtreecommitdiffstats
path: root/fs/lockd
diff options
context:
space:
mode:
authorTrond Myklebust <trond.myklebust@hammerspace.com>2023-09-11 14:43:57 -0400
committerChuck Lever <chuck.lever@oracle.com>2023-10-16 12:44:01 -0400
commit1b2021bdeeca12364ad0fa7aac9ddba5cae964f3 (patch)
tree06deaf5515153c5f266120c5e5aff0a65e349e08 /fs/lockd
parentd59b3515ab021e010fdc58a8f445ea62dd2f7f4c (diff)
downloadlinux-stable-1b2021bdeeca12364ad0fa7aac9ddba5cae964f3.tar.gz
linux-stable-1b2021bdeeca12364ad0fa7aac9ddba5cae964f3.tar.bz2
linux-stable-1b2021bdeeca12364ad0fa7aac9ddba5cae964f3.zip
nfsd: Don't reset the write verifier on a commit EAGAIN
If fsync() is returning EAGAIN, then we can assume that the filesystem being exported is something like NFS with the 'softerr' mount option enabled, and that it is just asking us to replay the fsync() operation at a later date. If we see an ESTALE, then ditto: the file is gone, so there is no danger of losing the error. For those cases, do not reset the write verifier. A write verifier change has a global effect, causing retransmission by all clients of all uncommitted unstable writes for all files, so it is worth mitigating where possible. Link: https://lore.kernel.org/linux-nfs/20230911184357.11739-1-trond.myklebust@hammerspace.com/ Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'fs/lockd')
0 files changed, 0 insertions, 0 deletions