Re: RFC: Does ZFS block cloning do this?

On Wed, Aug 6, 2025 at 9:28 AM Alexander Motin <mav@freebsd.org> wrote:
>
> 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.
For NFSv4.2 (which I suspect was modelled after what Linux does) the
difference is the ability to complete the entire "copy" within 1-2sec under
normal circumstances.
--> The NFSv4.2 CLONE operation requires this.
whereas for the NFSv4.2 COPY
--> It is allowed to return after a partial completion to adhere to the 1-2sec
      rule. This probably does not affect ZFS, but it is needed for
the "in general"
      UFS case.

There may be no difference needed for zfs_copy_file_range(). So long as it
never returns after a partial completion. If it does return after
partial completion,
a flag would indicate "must complete it".

As for FreeBSD syscalls, I don't see a need for a new one.
I'll leave that up to others.
pathconf(2) could be used to determine if cloning is supported.

Thanks for all the comments. It looks like a new "kernel only" flag for
VOP_COPY_FILE_RANGE() and a new name for VOP_PATHCONF()
should be all that is needed.

rick

>
> --
> Alexander Motin