Re: What is needed for ZFS block cloning to work?
Alexander Leidinger <[email protected]> Mon, 13 Jul 2026 09:27:01 +0200
| Newsgroups | gmane.os.freebsd.devel.file-systems |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --19f5a5f493e23272805afdda14 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Hi, We have the possibility to provide extended error info to the userland since 15.0 release. See commit 7211cd2cce74 for how to do that. Bye, Alexander. -- Send from a mobile device, please forgive brevity and misspellings. Am 13. Juli 2026 02:08:17 schrieb "Rob Norris" <[email protected]>: > 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? > > 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. > > Rob. --19f5a5f493e23272805afdda14 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.= w3.org/TR/html4/loose.dtd"> <html> <body> <div dir=3D"auto"> <div dir=3D"auto">Hi, </div><div dir=3D"auto"><br></div><div dir=3D"au= to">We have the possibility to provide extended error info to the userland = since 15.0 release.</div><div dir=3D"auto"><br></div><div dir=3D"auto">See = commit 7211cd2cce74 for how to do that. </div><div dir=3D"auto"><br></= div><div dir=3D"auto">Bye, </div><div dir=3D"auto">Alexander. </d= iv><div dir=3D"auto"><br></div><div id=3D"aqm-signature" dir=3D"auto" style= =3D"color: black;"><div dir=3D"auto">-- </div><div dir=3D"auto">Send f= rom a mobile device, please forgive brevity and misspellings.</div></div><d= iv dir=3D"auto"><br></div> <div id=3D"aqm-original" style=3D"color: black;"> <!-- body start --> <div class=3D"aqm-original-body"><div style=3D"color: black;"> <p style=3D"color: black; font-size: 10pt; font-family: sans-serif; margin:= 8pt 0;">Am 13. Juli 2026 02:08:17 schrieb "Rob Norris" <robn@despairlab= s.com>:</p> <blockquote type=3D"cite" class=3D"gmail_quote" style=3D"margin: 0 0 0 0.75= ex; border-left: 1px solid #808080; padding-left: 0.75ex;"> <div>On Mon, 13 Jul 2026, at 6:01 AM, John F Carr wrote:<br></div><blockquo= te type=3D"cite" id=3D"qt" style=3D""><div>Is copy_file_range supposed to u= se cloning when copying between children of</div><div>the same encrypted fi= lesystem? Or only within a filesystem?</div></blockquote><div><br></d= iv><div>Within the same "clone group", which is a filesystem/zvol, its snap= shots, and clones created from those snapshots (ie via zfs clone). All data= sets within such a group share a master key, so a block created in one can = be decrypted in another.</div><div><br></div><div>Note that "clone group" i= s not the same thing as "encryption root" - datasets with the same encrypti= on root share a wrapping key, but not necessarily the same master key.</div= ><div><br></div><div>I'll note here a possible misunderstanding that I see = a lot. For copy_file_range(), block cloning is an implementation detail. co= py_file_range()'s purpose is to ask the kernel to make a logical copy of so= me data, by whatever means its chooses. It's reasonable to wonder about whe= n cloning is chosen as an academic exercise, but the only thing the call gu= arantees on success is that reading back the source and destination will yi= eld the same bytes; the underlying structure is irrelevant.</div><div><br><= /div><div>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 i= s (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 inspect= ing the underlying structure of the object in question (ZFS on Linux implem= ents FICLONERANGE but not FIEMAP, yet). A richer error/result return path w= ould 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 thi= ngs.</div><div><br></div><div>Rob.</div></blockquote> </div> </div> <!-- body end --> </div><div dir=3D"auto"><br></div> </div></body> </html> --19f5a5f493e23272805afdda14--