I don't know why, and I still don't believe it, but splice with middler pipe is faster than direct splice. See https://github.com/uutils/coreutils/pull/12651#issue-4598546707 .
Not sure. Did this change broke measurement accuracy if inpit is coming from splice? ivarch/pv#200
The most reliable ways to check that we can bypass middler pipe, and use copy_file_range are just trying direct splice and copy_file_range for given fd's.
Closing since this appears between main and latest stable (thus, people no longer see this). Thankyou for e74cab6985 .
Unfortunately, --disable-copy-file-range improved performance on tmpfs to tmpfs (repeat and format is omitted):
I cannot see ---> at pv to tmpfs from btrfs. So it seems cross-device copy_file_range is not supported.
copy_file_range (or sendfile) internally splice's on non- CoW system. Can we change middler pipe size in the case? cross-device copy by splice might faster than copy_file_range.
I think read fallback is enough (no one tries to use pv -X under container).
I should benchmark splice to /dev/null vs splice to pipe & regenerate pipe with fcntl.
Is this for performance (with pv splice)? I have a pending PR on uutils/tee to support zero-copy and I guess GNU coreutils will do that soon.
And exit code 0 is not suitable for scripts.
I considered that /dev/null is useful only on Linux since splice is Linux specific.