On Sun, Jan 28, 2024 at 2:31 AM Antonio SJ Musumeci <trapexit@xxxxxxxxxx> wrote: > > Hello, > > Has anyone investigated adding support for FICLONE and FICLONERANGE? I'm > not seeing any references to either on the mailinglist. I've got a > passthrough filesystem and with more users taking advantage of btrfs and > xfs w/ reflinks there has been some demand for the ability to support it. > [CC fsdevel because my answer's scope is wider than just FUSE] FWIW, the kernel implementation of copy_file_range() calls remap_file_range() (a.k.a. clone_file_range()) for both xfs and btrfs, so if your users control the application they are using, calling copy_file_range() will propagate via your fuse filesystem correctly to underlying xfs/btrfs and will effectively result in clone_file_range(). Thus using tools like cp --reflink, on your passthrough filesystem should yield the expected result. For a more practical example see: https://bugzilla.samba.org/show_bug.cgi?id=12033 Since Samba 4.1, server-side-copy is implemented as copy_file_range() API-wise, there are two main differences between copy_file_range() and FICLONERANGE: 1. copy_file_range() can result in partial copy 2. copy_file_range() can results in more used disk space Other API differences are minor, but the fact that copy_file_range() is a syscall with a @flags argument makes it a candidate for being a super-set of both functionalities. The question is, for your users, are you actually looking for clone_file_range() support? or is best-effort copy_file_range() with clone_file_range() fallback enough? If your users are looking for the atomic clone_file_range() behavior, then a single flag in fuse_copy_file_range_in::flags is enough to indicate to the server that the "atomic clone" behavior is wanted. Note that the @flags argument to copy_file_range() syscall does not support any flags at all at the moment. The only flag defined in the kernel COPY_FILE_SPLICE is for internal use only. We can define a flag COPY_FILE_CLONE to use either only internally in kernel and in FUSE protocol or even also in copy_file_range() syscall. Sure, we can also add a new FUSE protocol command for FUSE_CLONE_FILE_RANGE, but I don't think that is necessary. It is certainly not necessary if there is agreement to extend the copy_file_range() syscall to support COPY_FILE_CLONE flag. What do folks think about this possible API extension? Thanks, Amir.
