Re: RFC: Does ZFS block cloning do this?
- Reply: Rick Macklem : "Re: RFC: Does ZFS block cloning do this?"
- In reply to: Rick Macklem : "Re: RFC: Does ZFS block cloning do this?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 06 Aug 2025 16:28:44 UTC
Hi Rick, On 8/6/25 11:54, Rick Macklem wrote: > The difference for NFSv4.2 is that CLONE cannot return with partial completion. > (It assumes that a CLONE of any size will complete quickly enough for an RPC. > Although there is no fixed limit, most assume an RPC reply should happen in > 1-2sec at most. For COPY, the server can return with only part of the > copy done.) > It also includes alignment restrictions for the byte offsets. > > There is also the alignment restriction on CLONE. There doesn't seem to be > an alignment restriction on zfs_clone_range(), but maybe it is buried inside it? > I think adding yet another pathconf name to get the alignment requirement and > whether or not the file system supports it would work without any VOP change. The semantics you describe looks similar to Linux FICLONE/FICLONERANGE calls, that got adopted there before copy_file_range(). IIRC those effectively mean -- clone the file or its range as requested or fail. I am not sure why some people prefer those calls, explicitly not allowing fallback to copy, but theere are some, for example Veeam backup fails if ZFS rejects the cloning request for any reason. For Linux ZFS has a separate code (see zpl_remap_file_range() and respective VFS calls) wrapping around block cloning to implement this semantics. FreeBSD does not have the equivalent at this point, but it would be trivial to add, if we really need those VOPs. -- Alexander Motin