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

> On Jul 12, 2026, at 18:18, Rick Macklem <rick.macklem@gmail.com> wrote:
> 
> 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.

^T showed me a stack trace in the fallback copy function in the kernel.
I used dtrace to see that the ZFS clone function was returning EXDEV
and the cause was the unequal encryption keys.  After that the details
didn't matter.  If copy_file_range usually clones, barring the occasional
cosmic ray or whatever, I'll treat copies as cheap.  It doesn't clone across
filesystems when encryption is involved so I'll treat copying terabytes as
expensive.

John