Re: Is 14.0 to released based on 0 for sysctl vfs.zfs.bclone_enabled ?
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 06 Nov 2023 00:43:50 UTC
On Nov 5, 2023, at 16:27, Martin Matuška <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. From 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=0 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=0 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. > > 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 <mike@karels.net> 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 <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 >> >> 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 >> >> 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