Re: Is 14.0 to released based on 0 for sysctl vfs.zfs.bclone_enabled ?

From: Mark Millard <marklmi_at_yahoo.com>
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