On Sunday, January 28th, 2024 at 4:07 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > 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. cp --reflink calls FICLONE. It received a EOPNOTSUPP and falls back to copying normally (if set to auto mode). It appears it still does this: https://github.com/coreutils/coreutils/blob/master/src/copy.c#L1509 My users don't control the software they are running. They are using random tooling that happen to support FICLONE such as cp --reflink. In the most recent case using it for some rsnapshot like backup strategy I believe.
