From nobody Mon Nov 06 00:34:32 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SNsmr1TSGz50GRn for ; Mon, 6 Nov 2023 00:34:36 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from www541.your-server.de (www541.your-server.de [213.133.107.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SNsmq4fj7z3RV8 for ; Mon, 6 Nov 2023 00:34:35 +0000 (UTC) (envelope-from mm@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 213.133.107.7 is neither permitted nor denied by domain of mm@FreeBSD.org) smtp.mailfrom=mm@FreeBSD.org; dmarc=none Received: from sslproxy06.your-server.de ([78.46.172.3]) by www541.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qznZa-000Cdw-8q for freebsd-stable@freebsd.org; Mon, 06 Nov 2023 01:34:34 +0100 Received: from [188.167.171.2] (helo=[10.0.9.225]) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qznZZ-000331-4e for freebsd-stable@freebsd.org; Mon, 06 Nov 2023 01:34:33 +0100 Message-ID: <05b493bc-94a5-4c78-bebf-5581addc5b7b@FreeBSD.org> Date: Mon, 6 Nov 2023 01:34:32 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Martin Matuska Subject: Re: Is 14.0 to released based on 0 for sysctl vfs.zfs.bclone_enabled ? To: FreeBSD-STABLE Mailing List References: <2F81D978-7DBD-42CE-8ECF-C020B0CB5C29.ref@yahoo.com> <2F81D978-7DBD-42CE-8ECF-C020B0CB5C29@yahoo.com> <7a906956-6836-421e-b25e-ff701369e3ed@FreeBSD.org> <830CD3A8-DB62-418D-A7F7-8DA6CB46B1F5@yahoo.com> Content-Language: en-US In-Reply-To: <830CD3A8-DB62-418D-A7F7-8DA6CB46B1F5@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-Sender: martin@matuska.de X-Virus-Scanned: Clear (ClamAV 0.103.10/27083/Sun Nov 5 08:43:13 2023) X-Spamd-Result: default: False [-1.25 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.987]; NEURAL_HAM_SHORT(-0.17)[-0.171]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.133.96.0/19, country:DE]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_SOFTFAIL(0.00)[~all:c]; FREEFALL_USER(0.00)[mm]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_X_AS(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4SNsmq4fj7z3RV8 X-Spamd-Bar: - 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 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 2023-05-25 20:53:08 +0000 > committer GitHub 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 > 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 > >