The 1.8.0 release candidate has a new feature where it can copy data by asking the file system to do it directly, instead of first reading and then writing the data itself. Per the feature description:
This can be used to optimise copies on network filesystems, improve speed of large copies or clone the data using copy-on-write functionality if the underlying filesystem supports it.
The details of what is supported on which OS and filesystem are somewhat hairy. However, if you’re running Linux with BTRFS or ZFS or (maybe?) ZFS, or ZFS on FreeBSD, or Windows with ReFS, CsvFS or a modern CIFS file share, you might see improved performance and/or reduced space usage.
However this is not well tested on all possible systems, so we’d greatly appreciate some help in seeing what works and what doesn’t.
This is not without risk. Please do testing on a less critical system, and only with a good backup of your data available. Minimizing that risk for regular users is why we’re asking intrepid ones to do testing.
Enabling the feature requires setting the appropriate value for the advanced folder option copyRangeMethod. The documentation is here:
Or reused from existing file, namely you have file A and make a copy of it as file B, it should reference blocks from file A and not take up any more space.
And, for the record, copy_file_range, ioctl and sendfile all fail on macOS 10.15.6 Catalina on an APFS destination. (TBH I don’t know if macOS yet supports the necessary commands to CoW-copy a block range.)
I don’t think it has any effect on zfs as zfs does not reuse blocks of the filesystem, it reuses the whole filesystem as you snapshot, so there are no per file optimisations.