summaryrefslogtreecommitdiff
path: root/fs/netfs/output.c
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2024-05-07 09:37:14 -0400
committerChuck Lever <chuck.lever@oracle.com>2024-05-09 09:10:48 -0400
commit8d915bbf39266bb66082c1e4980e123883f19830 (patch)
tree1e060341ef961cbc9b379b47bb08556661ae4099 /fs/netfs/output.c
parentbafa6b4d95d97877baa61883ff90f7e374427fae (diff)
NFSD: Force all NFSv4.2 COPY requests to be synchronous
We've discovered that delivering a CB_OFFLOAD operation can be unreliable in some pretty unremarkable situations. Examples include: - The server dropped the connection because it lost a forechannel NFSv4 request and wishes to force the client to retransmit - The GSS sequence number window under-flowed - A network partition occurred When that happens, all pending callback operations, including CB_OFFLOAD, are lost. NFSD does not retransmit them. Moreover, the Linux NFS client does not yet support sending an OFFLOAD_STATUS operation to probe whether an asynchronous COPY operation has finished. Thus, on Linux NFS clients, when a CB_OFFLOAD is lost, asynchronous COPY can hang until manually interrupted. I've tried a couple of remedies, but so far the side-effects are worse than the disease and they have had to be reverted. So temporarily force COPY operations to be synchronous so that the use of CB_OFFLOAD is avoided entirely. This is a fix that can easily be backported to LTS kernels. I am working on client patches that introduce an implementation of OFFLOAD_STATUS. Note that NFSD arbitrarily limits the size of a copy_file_range to 4MB to avoid indefinitely blocking an nfsd thread. A short COPY result is returned in that case, and the client can present a fresh COPY request for the remainder. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'fs/netfs/output.c')
0 files changed, 0 insertions, 0 deletions