copy_file_range(2): add recommendation to use large "len"
PR#252358 reported a serious performance problem w.r.t. cp(1) when copying large non-sparse files. This problem appears to have been caused by cp(1) calling copy_file_range(2) with a small "len" argument. This patch adds a recommendation to use a large "len" value where possible, for performance reasons. Reviewed by: asomers Differential Revision: https://reviews.freebsd.org/D27935
This commit is contained in:
parent
c98a764c68
commit
d189a74dfd
@ -25,7 +25,7 @@
|
|||||||
.\"
|
.\"
|
||||||
.\" $FreeBSD$
|
.\" $FreeBSD$
|
||||||
.\"
|
.\"
|
||||||
.Dd March 30, 2020
|
.Dd January 2, 2021
|
||||||
.Dt COPY_FILE_RANGE 2
|
.Dt COPY_FILE_RANGE 2
|
||||||
.Os
|
.Os
|
||||||
.Sh NAME
|
.Sh NAME
|
||||||
@ -117,6 +117,15 @@ with
|
|||||||
.Dv SEEK_DATA
|
.Dv SEEK_DATA
|
||||||
arguments and this system call for the
|
arguments and this system call for the
|
||||||
data ranges found.
|
data ranges found.
|
||||||
|
.Pp
|
||||||
|
For best performance, call
|
||||||
|
.Fn copy_file_range
|
||||||
|
with the largest
|
||||||
|
.Fa len
|
||||||
|
value possible.
|
||||||
|
It is interruptible on most file systems,
|
||||||
|
so there is no penalty for using very large len values, even SSIZE_MAX.
|
||||||
|
.Pp
|
||||||
.Sh RETURN VALUES
|
.Sh RETURN VALUES
|
||||||
If it succeeds, the call returns the number of bytes copied, which can be fewer
|
If it succeeds, the call returns the number of bytes copied, which can be fewer
|
||||||
than
|
than
|
||||||
|
Loading…
x
Reference in New Issue
Block a user