From 8f13abb4fd2f3c5d25bde830607a4aec6cec42d9 Mon Sep 17 00:00:00 2001 From: Rick Macklem Date: Mon, 18 Mar 2024 15:40:41 -0700 Subject: [PATCH] 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. Reviewed by: karels, wollman, pauamma_gundo.com (manpages) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D44395 --- 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 df73661169df..9051df4bcb31 100644 --- a/usr.sbin/nfsd/nfsd.8 +++ b/usr.sbin/nfsd/nfsd.8 @@ -25,7 +25,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.Dd March 22, 2023 +.Dd March 16, 2024 .Dt NFSD 8 .Os .Sh NAME @@ -353,3 +353,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.