support copy_file_range() syscall

[derekdai]

This is a interesting new syscall first appeared in linux kernel 4.4 that offloaded file copy from user space to kernel, and I think this is a great way to implement a lightweight copying in between zfs file systems. Is there a plan to support it on ZoL?

[DeHackEd]

At the end of the day ZFS doesn't have anything to offer which "accelerates" the process. This system call merely removes the copies from user and kernel spaces. In most situations that's not going to be substantially faster than your disks or controllers can perform the IO.

[NobodyXu]

Wine now uses this syscall to deduplicate system files according to here, so it might be a good idea to support copy_file_range with reflink support.

[derekdai]

The storage won't go faster because of this syscall, but it saves resources from

• Prevent data from been copy to and from kernel and user space
• zfs can choose the best block size to copy to and from
• zfs don't need to recalculate checksum
• zfs don't need to decompress blocks
• zfs can do deduplication more efficiently

[lundman]

Also, macOS needs vnop_clonefile and vnop_exchange (which would like to use reflink) It is more about these operations being atomic. Either completes as a whole, or is cleaned up, with optional clone/exchange of xattrs, so keep that in mind if someone were to implement it :)

[baryluk]

FYI. copy_file_range is implemented on few Linux file systems, with varying level of optimisations:

• btrfs - uses CoW reflinking
• ext4 - reflinking extents, fallbacks to fast page cache copying
• xfs - ditto
• cifs - server side copy
• nfs - server side copy (and if server supports CoW on backend storage)
• fuse - whatever userspace app wants it to be
• overlayfs - delegates to upperdir

There were btrfs and xfs specific ioctls in the past to do similar, but now it is more standarized.

Would be nice to see this in ZFS somehow. As others mentioned, wine / proton uses this to reduce file duplication between wine prefixes.

This syscall is readily available in many programming languages, including C / glibc, Python 3.8, golang, Rust.

Also older versions of GNU coreutils cp used this btrfs ioctl, newer versions do utilize copy_file_range and do have it enabled by default for some scenarios (and fallback to other methods if needed i.e. running on very old kernel).

[rincebrain]

I have this wired up minimally successfully to the BRT PR, though there are quirks in that case when using it cross-filesystem due to Linux hardcoding restrictions on things.

Though I would point out that as FreeBSD recently encountered with their copy_file_range implementation, just because one would expect it to be faster to use doesn't make it so...

[ryao]

@rincebrain What are the quirks?

[ryao]

The btrfs IOCTLs were promoted to FICLONE and FICLONERANGE:

https://www.man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html

[ryao]

I would prefer to coordinate with the coreutils developers to get support for a ZFS specific ioctl into coreutils and then let support gradually make its way into distributions. It is better than the real possibility of doing nothing from being blocked on mainline.

If we were to make zfs cp people would expect us to keep it around forever. It is okay if cross mount reflinks do not work until the newer coreutils gets to users. It is likely a rare use case.

[rincebrain]

I personally would call that unacceptable, because one of my big use cases is that.

I can't find any evidence in quickly searching coreutils' git tree that they ever supported BTRFS_IOC_FILE_EXTENT_SAME and friends. Based on the previous exchange and that, I would suspect they would tell us to go work with Linux on a solution instead.

e: You know, I post that, and hit enter to close my scrolling, and one page later...

coreutils/coreutils@4533017

[ryao]

I can't find any evidence in quickly searching coreutils' git tree that they ever supported BTRFS_IOC_FILE_EXTENT_SAME and friends. Based on the previous exchange and that, I would suspect they would tell us to go work with Linux on a solution instead.

I think it would be better to ask them and get their opinion rather than deciding it ourselves. Otherwise, they could be willing to do it and we would not take advantage of that solely because we did not ask.

I personally would call that unacceptable, because one of my big use cases is that.

You can install newer coreutils versions yourself in /usr/local. It is also not hard to make an out of tree tool for using it that we don't have to commit to maintaining ad infinitum.

[baryluk]

While I would also would love this supported, there is no point rushing it. It is probably better to clarify things with VFS maintainers, and even if it take a year or two to get a proper solution, than some ioctl hack, that is still a better solution.