OpenZFS 2.2.0 in FreeBSD 14 fully supports block cloning. You can work
with pools that have feature@block_cloning enabled.
The sysctl variable vfs.zfs.bclone_enabled affects the behavior of
zfs_clone_range() which is called by copy_file_range(). When it is set
to 0, zfs_clone_range() does not do block cloning.
If it is set to anything else than 0, zfs_clone_range() does block
cloning (if all conditions are met - same ZFS pool, correct data
alignment, etc.).
In FreeBSD-main, this tunable is enabled and I plan to enable it in
stable/14 somewhere around December 11, 2023.
As of today I personally use block cloning on all my systems.
mm
On 04/11/2023 13:35, Mark Millard wrote:
On Nov 4, 2023, at 04:38, Mike Karels <[email protected]> wrote:
On 4 Nov 2023, at 4:01, Ronald Klop wrote:
On 11/4/23 02:39, Mark Millard wrote:
It looks to me like releng/14.0 (as of 14.0-RC4) still has:
int zfs_bclone_enabled;
SYSCTL_INT(_vfs_zfs, OID_AUTO, bclone_enabled, CTLFLAG_RWTUN,
&zfs_bclone_enabled, 0, "Enable block cloning");
leaving block cloning effectively disabled by default, no
matter what the pool has enabled.
https://www.freebsd.org/releases/14.0R/relnotes/ also reports:
QUOTE
OpenZFS has been upgraded to version 2.2. New features include:
•
block cloning, which allows shallow copies of blocks in file
copies. This is optional, and disabled by default; it can be
enabled with sysctl vfs.zfs.bclone_enabled=1.
END QUOTE
I think this answers your question in the subject.
I think so too (and I wrote that text).
Thanks for the confirmation of the final intent.
I believe this makes:
QUOTE
author Brian Behlendorf <[email protected]> 2023-05-25 20:53:08 +0000
committer GitHub <[email protected]> 2023-05-25 20:53:08 +0000
commit 91a2325c4a0fbe01d0bf212e44fa9d85017837ce (patch)
tree dd01dfce6aeef357ade1775acf18aade535c6271
. . .
Update compatibility.d files
Add an openzfs-2.2 compatibility file for the next release. Edon-R
support has been enabled for FreeBSD removing the need for different
FreeBSD and Linux files. Symlinks for the -linux and -freebsd names
are created for any scripts expecting that convention. Additionally, a
symlink for ubunutu-22.04 was added. Signed-off-by: Brian Behlendorf
<[email protected]> Closes #14833
END QUOTE
technically incorrect in that compatibility.d/openzfs-2.2-freebsd
should be distinct in content from compatibility.d/openzfs-2.2 so
that block cloning would not be enabled.
Just curiousity on my part about the default completeness of
openzfs-2.2 support, not an objection either way.
I haven't seen new issues with block cloning in the last few weeks
mentioned on the mailing lists. All known issues are fixed AFAIK.
But I can imagine that the risk+effect ratio of data corruption is
seen as a bit too high for a 14.0 release for this particular
feature. That does not diminish the rest of the completeness of
openzfs-2.2.
NB: I'm not involved in developing openzfs or the decision making in
the release. Just repeating what I read on the lists.
There was another block cloning fix in 14.0-RC4; see the commit log.
Maybe there will be no more issues, but it seems that corner cases were
still being found recently.
Looks like I'll stay at openzfs-2.1 pool features until there is
a release that no longer has the default status:
0 for sysctl vfs.zfs.bclone_enabled
I use main [so: 15 now] but only enable openzfs-2.* pool features
supported by default on some FreeBSD release, that has an accurate
compatibility.d/openzfs-2.*-freebsd file.
===
Mark Millard
marklmi at yahoo.com
