upstream/opnsense-src
1
0
Fork 0
mirror of https://github.com/opnsense/src.git synced 2026-06-09 00:32:25 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

nfsd.8: Document ways to minimize Copy operation times

Browse source 
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 8f13abb4fd)
This commit is contained in:
Rick Macklem 2024-03-18 15:40:41 -07:00
parent 811bd332ab
commit 71f16d2efe
1 changed files with 23 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
usr.sbin/nfsd/nfsd.8
View file

@ -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.