Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Aug 2025 10:20:27 -0600
From:      Alan Somers <asomers@freebsd.org>
To:        Rick Macklem <rick.macklem@gmail.com>
Cc:        FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   Re: RFC: Does ZFS block cloning do this?
Message-ID:  <CAOtMX2iFw3juTNHdTFCEZ8G-Jd_t-e2KmG3pb35YiPE4zd%2B5WQ@mail.gmail.com>
In-Reply-To: <CAM5tNy6PJbTnjf24L0Y9j5NicBTZHDBKp%2BaF-VhOLCsaY5Qbnw@mail.gmail.com>
References:  <CAM5tNy7V7Btem%2ByWNK7oyn9qsk6TrQwuGo1kxqhCstLM4_uh9g@mail.gmail.com> <CAOtMX2jGcQY_AywWv1tVBbAk%2BrOheya%2BHRQBMRDc7ELGrA7qNA@mail.gmail.com> <CAM5tNy6PJbTnjf24L0Y9j5NicBTZHDBKp%2BaF-VhOLCsaY5Qbnw@mail.gmail.com>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On Wed, Aug 6, 2025 at 9:54 AM Rick Macklem <rick.macklem@gmail.com> wrote:

> On Wed, Aug 6, 2025 at 8:32 AM Alan Somers <asomers@freebsd.org> wrote:
> >
> > On Wed, Aug 6, 2025 at 9:18 AM Rick Macklem <rick.macklem@gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> NFSv4.2 has a CLONE operation. It is described as doing:
> >>    The CLONE operation is used to clone file content from a source file
> >>    specified by the SAVED_FH value into a destination file specified by
> >>    CURRENT_FH without actually copying the data, e.g., by using a
> >>    copy-on-write mechanism.
> >> (It takes arguments for 2 files, with byte offsets and a length.)
> >> The offsets must be aligned to a value returned by the NFSv4.2 server.
> >> 12.2.1.  Attribute 77: clone_blksize
> >>
> >>    The clone_blksize attribute indicates the granularity of a CLONE
> >>    operation.
> >>
> >> Does ZFS block cloning do this?
> >>
> >> I am asking now, because although it might be too late,
> >> if the answer is "yes", I'd like to get VOP calls into 15.0
> >> for it. (Hopefully with the VOP calls in place, the rest could
> >> go in sometime later, when I find the time to do it.)
> >>
> >> Thanks in advance for any comments, rick
> >
> >
> > Yes, it does that right now, if the feature@block_cloning pool
> attribute is enabled.  It works with VOP_COPY_FILE_RANGE.  Does NFS really
> need a new VOP?
> Either a new VOP or maybe a new flag argument for VOP_COPY_FILE_RANGE().
> Linux defined a flag argument for their copy_file_range(), but they have
> never
> defined any flags. Of course, that doesn't mean there cannot be a
> "kernel internal"
> flag.
>
> So maybe adding a new VOP can be avoided. That would be nice, given the
> timing
> of the 15.0 release and other churn going on.
>
> 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.
>
> rick
>

zfs_clone_range doesn't have any alignment restrictions.  But if the
argument isn't aligned to a record boundary, ZFS will actually copy a
partial record, rather than clone it.  Regarding the copy-to-completion
requirement, could that be implemented within nfs by looping over
VOP_COPY_FILE_RANGE?

[-- Attachment #2 --]
<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Aug 6, 2025 at 9:54 AM Rick Macklem &lt;<a href="mailto:rick.macklem@gmail.com">rick.macklem@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Aug 6, 2025 at 8:32 AM Alan Somers &lt;<a href="mailto:asomers@freebsd.org" target="_blank">asomers@freebsd.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wed, Aug 6, 2025 at 9:18 AM Rick Macklem &lt;<a href="mailto:rick.macklem@gmail.com" target="_blank">rick.macklem@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; NFSv4.2 has a CLONE operation. It is described as doing:<br>
&gt;&gt;    The CLONE operation is used to clone file content from a source file<br>
&gt;&gt;    specified by the SAVED_FH value into a destination file specified by<br>
&gt;&gt;    CURRENT_FH without actually copying the data, e.g., by using a<br>
&gt;&gt;    copy-on-write mechanism.<br>
&gt;&gt; (It takes arguments for 2 files, with byte offsets and a length.)<br>
&gt;&gt; The offsets must be aligned to a value returned by the NFSv4.2 server.<br>
&gt;&gt; 12.2.1.  Attribute 77: clone_blksize<br>
&gt;&gt;<br>
&gt;&gt;    The clone_blksize attribute indicates the granularity of a CLONE<br>
&gt;&gt;    operation.<br>
&gt;&gt;<br>
&gt;&gt; Does ZFS block cloning do this?<br>
&gt;&gt;<br>
&gt;&gt; I am asking now, because although it might be too late,<br>
&gt;&gt; if the answer is &quot;yes&quot;, I&#39;d like to get VOP calls into 15.0<br>
&gt;&gt; for it. (Hopefully with the VOP calls in place, the rest could<br>
&gt;&gt; go in sometime later, when I find the time to do it.)<br>
&gt;&gt;<br>
&gt;&gt; Thanks in advance for any comments, rick<br>
&gt;<br>
&gt;<br>
&gt; Yes, it does that right now, if the feature@block_cloning pool attribute is enabled.  It works with VOP_COPY_FILE_RANGE.  Does NFS really need a new VOP?<br>
Either a new VOP or maybe a new flag argument for VOP_COPY_FILE_RANGE().<br>
Linux defined a flag argument for their copy_file_range(), but they have never<br>
defined any flags. Of course, that doesn&#39;t mean there cannot be a<br>
&quot;kernel internal&quot;<br>
flag.<br>
<br>
So maybe adding a new VOP can be avoided. That would be nice, given the timing<br>
of the 15.0 release and other churn going on.<br>
<br>
The difference for NFSv4.2 is that CLONE cannot return with partial completion.<br>
(It assumes that a CLONE of any size will complete quickly enough for an RPC.<br>
Although there is no fixed limit, most assume an RPC reply should happen in<br>
1-2sec at most. For COPY, the server can return with only part of the<br>
copy done.)<br>
It also includes alignment restrictions for the byte offsets.<br>
<br>
There is also the alignment restriction on CLONE. There doesn&#39;t seem to be<br>
an alignment restriction on zfs_clone_range(), but maybe it is buried inside it?<br>
I think adding yet another pathconf name to get the alignment requirement and<br>
whether or not the file system supports it would work without any VOP change.<br>
<br>
rick<br></blockquote><div><br></div><div>zfs_clone_range doesn&#39;t have any alignment restrictions.  But if the argument isn&#39;t aligned to a record boundary, ZFS will actually copy a partial record, rather than clone it.  Regarding the copy-to-completion requirement, could that be implemented within nfs by looping over VOP_COPY_FILE_RANGE? </div></div></div>
help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2iFw3juTNHdTFCEZ8G-Jd_t-e2KmG3pb35YiPE4zd%2B5WQ>