Date: Sun, 5 Nov 2023 16:43:50 -0800 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Martin_Matu=C5=A1ka?= <martin@matuska.de> Cc: Mike Karels <mike@karels.net>, Ronald Klop <ronald@FreeBSD.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Is 14.0 to released based on 0 for sysctl vfs.zfs.bclone_enabled ? Message-ID: <B981FAB0-1BF7-4251-8673-08E63A7A931A@yahoo.com> In-Reply-To: <ad348d20-9c4b-4979-be02-b79e53f27552@matuska.de> References: <2F81D978-7DBD-42CE-8ECF-C020B0CB5C29.ref@yahoo.com> <2F81D978-7DBD-42CE-8ECF-C020B0CB5C29@yahoo.com> <7a906956-6836-421e-b25e-ff701369e3ed@FreeBSD.org> <BBFDD30F-FB5D-44C8-ADA7-5B5AF859D86A@karels.net> <830CD3A8-DB62-418D-A7F7-8DA6CB46B1F5@yahoo.com> <ad348d20-9c4b-4979-be02-b79e53f27552@matuska.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 5, 2023, at 16:27, Martin Matu=C5=A1ka <martin@matuska.de> wrote: > 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.). Ahh. =46rom the naming and vague memories of the history, I did not = understand that vfs.zfs.bclone_enabled has a narrower set of consequences than the name = suggests and vfs.zfs.bclone_enabled=3D0 does not imply any lack of support for = pools that have block cloning active. May be the wording at, for example = https://www.freebsd.org/releases/14.0R/relnotes/ should be more explicit about the relationships involved when = vfs.zfs.bclone_enabled=3D0 since others may read in the same bad interpretation that I did. Thanks for the note. Very helpful. > In FreeBSD-main, this tunable is enabled and I plan to enable it in = stable/14 somewhere around December 11, 2023. >=20 > As of today I personally use block cloning on all my systems. >=20 > mm >=20 > On 04/11/2023 13:35, Mark Millard wrote: >> On Nov 4, 2023, at 04:38, Mike Karels <mike@karels.net> wrote: >>=20 >>> On 4 Nov 2023, at 4:01, Ronald Klop wrote: >>>=20 >>>> On 11/4/23 02:39, Mark Millard wrote: >>>>> It looks to me like releng/14.0 (as of 14.0-RC4) still has: >>>>>=20 >>>>> int zfs_bclone_enabled; >>>>> SYSCTL_INT(_vfs_zfs, OID_AUTO, bclone_enabled, CTLFLAG_RWTUN, >>>>> &zfs_bclone_enabled, 0, "Enable block cloning"); >>>>>=20 >>>>> leaving block cloning effectively disabled by default, no >>>>> matter what the pool has enabled. >>>>>=20 >>>>> https://www.freebsd.org/releases/14.0R/relnotes/ also reports: >>>>>=20 >>>>> QUOTE >>>>> OpenZFS has been upgraded to version 2.2. New features include: >>>>> =E2=80=A2 >>>>> 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=3D1. >>>>> END QUOTE >>>>>=20 >>>>=20 >>>> 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. >>=20 >> I believe this makes: >>=20 >> QUOTE >> author Brian Behlendorf <behlendorf1@llnl.gov> 2023-05-25 20:53:08 = +0000 >> committer GitHub <noreply@github.com> 2023-05-25 20:53:08 +0000 >> commit 91a2325c4a0fbe01d0bf212e44fa9d85017837ce (patch) >> tree dd01dfce6aeef357ade1775acf18aade535c6271 >> . . . >> Update compatibility.d files >>=20 >> 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 = <behlendorf1@llnl.gov> Closes #14833 >> END QUOTE >>=20 >> 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. >>=20 >>=20 >>>>> Just curiousity on my part about the default completeness of >>>>> openzfs-2.2 support, not an objection either way. >>>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> 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: >>=20 >> 0 for sysctl vfs.zfs.bclone_enabled >>=20 >> 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. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B981FAB0-1BF7-4251-8673-08E63A7A931A>