diff options
author | Trond Myklebust <trondmy@gmail.com> | 2019-09-02 20:02:58 +0300 |
---|---|---|
committer | J. Bruce Fields <bfields@redhat.com> | 2019-09-10 16:23:41 +0300 |
commit | bbf2f098838aa86cee240a7a11486e0601d56a3f (patch) | |
tree | c099d49e802180aa5616cb5a217ec4085f01aefa /fs/nfsd/nfs3xdr.c | |
parent | 055b24a8f23090043b2ce0c30f03e12c5f2c9e72 (diff) | |
download | linux-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