summaryrefslogtreecommitdiff
path: root/fs/nfsd/nfs3xdr.c
diff options
context:
space:
mode:
authorTrond Myklebust <trondmy@gmail.com>2019-09-02 20:02:58 +0300
committerJ. Bruce Fields <bfields@redhat.com>2019-09-10 16:23:41 +0300
commitbbf2f098838aa86cee240a7a11486e0601d56a3f (patch)
treec099d49e802180aa5616cb5a217ec4085f01aefa /fs/nfsd/nfs3xdr.c
parent055b24a8f23090043b2ce0c30f03e12c5f2c9e72 (diff)
downloadlinux-bbf2f098838aa86cee240a7a11486e0601d56a3f.tar.xz
nfsd: Reset the boot verifier on all write I/O errors
If multiple clients are writing to the same file, then due to the fact we share a single file descriptor between all NFSv3 clients writing to the file, we have a situation where clients can miss the fact that their file data was not persisted. While this should be rare, it could cause silent data loss in situations where multiple clients are using NLM locking or O_DIRECT to write to the same file. Unfortunately, the stateless nature of NFSv3 and the fact that we can only identify clients by their IP address means that we cannot trivially cache errors; we would not know when it is safe to release them from the cache. So the solution is to declare a reboot. We understand that this should be a rare occurrence, since disks are usually stable. The most frequent occurrence is likely to be ENOSPC, at which point all writes to the given filesystem are likely to fail anyway. So the expectation is that clients will be forced to retry their writes until they hit the fatal error. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'fs/nfsd/nfs3xdr.c')
0 files changed, 0 insertions, 0 deletions