Page MenuHomeFreeBSD

add recommendation for using a large "len" argument
ClosedPublic

Authored by rmacklem on Jan 2 2021, 11:04 PM.
Tags
None
Referenced Files
F80219705: D27935.id81559.diff
Fri, Mar 29, 8:08 AM
Unknown Object (File)
Feb 12 2024, 3:34 AM
Unknown Object (File)
Jan 7 2024, 3:55 PM
Unknown Object (File)
Dec 20 2023, 4:00 AM
Unknown Object (File)
Dec 12 2023, 12:20 PM
Unknown Object (File)
Nov 29 2023, 9:07 PM
Unknown Object (File)
Nov 11 2023, 12:29 PM
Unknown Object (File)
Nov 6 2023, 4:23 PM
Subscribers
None

Details

Summary

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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

rmacklem created this revision.
asomers requested changes to this revision.Jan 2 2021, 11:18 PM
asomers added inline comments.
lib/libc/sys/copy_file_range.2
144

I think this belongs in the DESCRIPTION section, not RETURN VALUES.

147

Why SSIZE_MAX? Since len is defined as a size_t, shouldn't the limit be SIZE_MAX ?

149

I think this qualifies as TMI. I might phrase it as "For best performance, call copy_file_range with the largest len value possible. It is interruptible on most file systems, so there is no penalty for using very large len values, even SSIZE_MAX."

This revision now requires changes to proceed.Jan 2 2021, 11:18 PM

Update patch as recommended by asomers@.

Handled inline comments.

lib/libc/sys/copy_file_range.2
147

Because it returns ssize_t.
I didn't think that needed to be stated here,
but if you think it should be, I can add a
sentence.

asomers added inline comments.
lib/libc/sys/copy_file_range.2
147

Ahh, that makes sense.

This revision is now accepted and ready to land.Jan 3 2021, 12:30 AM