Re: What is needed for ZFS block cloning to work?

On Sun, Jul 12, 2026 at 5:07 PM Rob Norris <robn@despairlabs.com> wrote:
>
> On Mon, 13 Jul 2026, at 6:01 AM, John F Carr wrote:
>
> Is copy_file_range supposed to use cloning when copying between children of
> the same encrypted filesystem?  Or only within a filesystem?
Did you see a EXDEV return from the copy_file_range(2) syscall or from
zfs_clone_range() inside the ZFS code?
If it was the latter, ZFS's VOP_COPY_FILE_RANGE() should return ENOSYS,
which gets the copy done via vn_generic_copy_file_range() in the syscall.
(vn_generic_copy_file_range() just loops around, doing VOP_READ()/VOP_WRITE().
It does try to find holes and that's why it can be slow when
vfs.zfs.dmu_offset_next_sync=1.

>
>
> Within the same "clone group", which is a filesystem/zvol, its snapshots, and clones created from those snapshots (ie via zfs clone). All datasets within such a group share a master key, so a block created in one can be decrypted in another.
>
> Note that "clone group" is not the same thing as "encryption root" - datasets with the same encryption root share a wrapping key, but not necessarily the same master key.
>
> I'll note here a possible misunderstanding that I see a lot. For copy_file_range(), block cloning is an implementation detail. copy_file_range()'s purpose is to ask the kernel to make a logical copy of some data, by whatever means its chooses. It's reasonable to wonder about when cloning is chosen as an academic exercise, but the only thing the call guarantees on success is that reading back the source and destination will yield the same bytes; the underlying structure is irrelevant.
>
> None of that is to say that it shouldn't be more controllable or predictable, but it would need more work. On Linux the FICLONERANGE ioctl is (effectively) the same as copy_file_range(), but it _must_ clone, or fail. Again on Linux, the FIEMAP ioctl or something like it would allow inspecting the underlying structure of the object in question (ZFS on Linux implements FICLONERANGE but not FIEMAP, yet). A richer error/result return path would allow us to return back to userspace why a clone didn't happen, but I'm not sure that there's any really pleasant facility out there for such things.

For FreeBSD, if cloning or failure of the copy_file_range(2) syscall is
desired, the flag argument COPY_FILE_RANGE_CLONE can be specified.
(to avoid the fallback to the copy loop in the kernel syscall)

rick

>
> Rob.