diff options
author | Rick Macklem <rmacklem@FreeBSD.org> | 2021-09-08 00:35:26 +0000 |
---|---|---|
committer | Rick Macklem <rmacklem@FreeBSD.org> | 2021-09-08 00:35:26 +0000 |
commit | c5128c48df3c2f3828432aff2ea536bb9c887e14 (patch) | |
tree | 0b1dfc203211a484377625d65109ecbd5d047b7a /crypto/openssh/regress/valgrind-unit.sh | |
parent | 92de737996660b70376a8b72b80037f89d876056 (diff) | |
download | src-c5128c48df3c2f3828432aff2ea536bb9c887e14.tar.gz src-c5128c48df3c2f3828432aff2ea536bb9c887e14.zip |
VOP_COPY_FILE_RANGE: Add a COPY_FILE_RANGE_TIMEO1SEC flag
Although it is not specified in the RFCs, the concept that
the NFSv4 server should reply to an RPC request within a
reasonable time is accepted practice within the NFSv4 community.
Without this patch, the NFSv4.2 server attempts to reply to
a Copy operation within 1second by limiting the copy to
vfs.nfs.maxcopyrange bytes (default 10Mbytes). This is crude at
best, given the large variation in I/O subsystem performance.
This patch adds a kernel only flag COPY_FILE_RANGE_TIMEO1SEC
that the NFSv4.2 can specify, which tells VOP_COPY_FILE_RANGE()
to return after approximately 1 second with a partial result and
implements this in vn_generic_copy_file_range(), used by
vop_stdcopyfilerange().
Modifying the NFSv4.2 server to set this flag will be done in
a separate patch. Also under consideration is exposing the
COPY_FILE_RANGE_TIMEO1SEC to userland for use on the FreeBSD
copy_file_range(2) syscall.
MFC after: 2 weeks
Reviewed by: khng
Differential Revision: https://reviews.freebsd.org/D31829
Diffstat (limited to 'crypto/openssh/regress/valgrind-unit.sh')
0 files changed, 0 insertions, 0 deletions