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 <<a href="mailto:rick.macklem@gmail.com">rick.macklem@gmail.com</a>> 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 <<a href="mailto:asomers@freebsd.org" target="_blank">asomers@freebsd.org</a>> wrote:<br> ><br> > On Wed, Aug 6, 2025 at 9:18 AM Rick Macklem <<a href="mailto:rick.macklem@gmail.com" target="_blank">rick.macklem@gmail.com</a>> wrote:<br> >><br> >> Hi,<br> >><br> >> NFSv4.2 has a CLONE operation. It is described as doing:<br> >> The CLONE operation is used to clone file content from a source file<br> >> specified by the SAVED_FH value into a destination file specified by<br> >> CURRENT_FH without actually copying the data, e.g., by using a<br> >> copy-on-write mechanism.<br> >> (It takes arguments for 2 files, with byte offsets and a length.)<br> >> The offsets must be aligned to a value returned by the NFSv4.2 server.<br> >> 12.2.1. Attribute 77: clone_blksize<br> >><br> >> The clone_blksize attribute indicates the granularity of a CLONE<br> >> operation.<br> >><br> >> Does ZFS block cloning do this?<br> >><br> >> I am asking now, because although it might be too late,<br> >> if the answer is "yes", I'd like to get VOP calls into 15.0<br> >> for it. (Hopefully with the VOP calls in place, the rest could<br> >> go in sometime later, when I find the time to do it.)<br> >><br> >> Thanks in advance for any comments, rick<br> ><br> ><br> > 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't mean there cannot be a<br> "kernel internal"<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'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'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? </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>
