The branch stable/13 has been updated by rmacklem:
URL:
https://cgit.FreeBSD.org/src/commit/?id=23a48a469a4e6ce7b69620084513a7bf9b0fb939
commit 23a48a469a4e6ce7b69620084513a7bf9b0fb939
Author: Rick Macklem <rmack...@freebsd.org>
AuthorDate: 2024-03-18 22:40:41 +0000
Commit: Rick Macklem <rmack...@freebsd.org>
CommitDate: 2024-04-01 02:16:36 +0000
nfsd.8: Document ways to minimize Copy operation times
For NFSv4.2, a Copy operation can take a long time to complete.
If there is a concurrent ExchangeID or DelegReturn operation
which requires the exclusive lock on all NFSv4 state, this can
result in a stall of the nfsd server.
This patch documents ways to avoid this problem.
This is a content change.
(cherry picked from commit 8f13abb4fd2f3c5d25bde830607a4aec6cec42d9)
---
usr.sbin/nfsd/nfsd.8 | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/usr.sbin/nfsd/nfsd.8 b/usr.sbin/nfsd/nfsd.8
index 0a9f6f82c85f..1c04bad3a042 100644
--- a/usr.sbin/nfsd/nfsd.8
+++ b/usr.sbin/nfsd/nfsd.8
@@ -27,7 +27,7 @@
.\"
.\" @(#)nfsd.8 8.4 (Berkeley) 3/29/95
.\"
-.Dd March 22, 2023
+.Dd March 16, 2024
.Dt NFSD 8
.Os
.Sh NAME
@@ -355,3 +355,25 @@ to be set to one on the MDS as a workaround.
Linux 5.n kernels appear to have been patched such that this
.Xr sysctl 8
does not need to be set.
+.Pp
+For NFSv4.2, a Copy operation can take a long time to complete.
+If there is a concurrent ExchangeID or DelegReturn operation
+which requires the exclusive lock on all NFSv4 state, this can
+result in a
+.Dq stall
+of the
+.Nm
+server.
+If your storage is on ZFS without block cloning enabled,
+setting the
+.Xr sysctl 8
+.Va vfs.zfs.dmu_offset_next_sync
+to 0 can often avoid this problem.
+It is also possible to set the
+.Xr sysctl 8
+.Va vfs.nfsd.maxcopyrange
+to 10-100 megabytes to try and reduce Copy operation times.
+As a last resort, setting
+.Xr sysctl 8
+.Va vfs.nfsd.maxcopyrange
+to 0 disables the Copy operation.
