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

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 <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
>
>