uu-cp is faster than cp

[desbma]

Not really an issue, but I thought you should know that on Linux uu-cp is measurably faster than Coreutils' cp.

The reason is that std::fs::copy internally makes use of sendfile or copy_file_range syscalls when it can, while the GNU cp maintainer has not yet added support, despite it being proposed several times (1 2).

On a tmpfs it can be around 5-10% faster for big files. On NFS it can probably be orders of magnitude faster because the copy can be done server side.

[sylvestre]

Great, thanks for the information. I guess we are benefiting from Rust great implementations!

[ylluminate]

How does uu-cp and other similar utils now compare with the increase brought by GNU Coreutils 9.5 Can Yield 10~20% Throughput Boost For cp, mv & cat Commands (phoronix article)?

[kanashimia]

It was reported that uutils uses copy_file_range syscall to copy files between ZFS datasets, where as gnu coreutils doesn't do so, on ZFS this causes COW clone and as such uutils cp is instantaneous compared to coreutils. Though this is worth knowing.

[desbma]

I believe GNU coreutil's cp has since changed to do CoW by default:

cp and install now default to copy-on-write (COW) if available.
I.e., cp now uses --reflink=auto mode by default.

https://github.com/coreutils/coreutils/blob/master/NEWS#L857

A part of me thinks this is due to indirect pressure created by issues like this one.

[kanashimia]

I believe GNU coreutil's cp has since changed to do CoW by default:

Yes.
At least that message above for ZFS it is quite recently reported, reflink flag does there nothing, I think because it considers different datasets as different filesystems and as such not suitable for reflink copy or something. Also interesting observation is that at least on btrfs gnu coreutlis seems to use ioctl FICLONERANGE instead copy_file_range for reflink copies.

[pixelb]

GNU cp does use copy_file_range() which is measurably faster on ZFS, especially with compression enabled.
This is in place since release 9.0 (2021-09-24)