From nobody Tue Apr 25 07:35:29 2023 X-Original-To: freebsd-current@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 4Q5DLs1Kc9z46ngw for ; Tue, 25 Apr 2023 07:35:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4Q5DLq3b7dz3R6n for ; Tue, 25 Apr 2023 07:35:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mVtRG8g2; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682408144; bh=NAJq8d7U3NLGB9nR0eVUBfdL6cY/rsBEj1h9izmT9Mk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=mVtRG8g2F1PkHT0mmWM+kiqeWZQUoaR0rmtuwmeNIRm90xOwRwFruw4EDTzqLq1+q4f9DmVtuIgr0z8JKUl2+vR+xMc8Eem2wpj7sDrr97xfOXZpwtKYDCCiAQ/DIY6WNBof0m460x25b2vibm6VqOsN+kJ+K1f4eXK6qFv7cfsBDZrayux1fdJzqyRg/81crN5YruxuntOtwMSmdNugng7BwvqPo5OaOrQWiGPn02g4Z2oVHG30MlcTFwKEHy67y6lM7IlCvXyFjoHEUlfBpowHUOCsQ1CYpkT5wisg1B7kPKzbmwDnXQ1M4vl88I6WZ6qBMd0zJmvIx0KEf4mtFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682408144; bh=y+CNSf+5LXXYS0OPfuyj17DKhaVVESDvvD4dlXMOCdR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=UPVKDKOpBQEEmXMKAi/y8IchzvOGuI54+1VnIdkmD3NuOyAL+qBlYd9G0dkXOXqcs3vbs72Lh/AYiYMDdfq4Q5eQrmZk8ZoXJR04FZGBUNDtofHIOtdM3Wnik4cWihdmitZbdgEhTUtLyrQ0PbCFGSj0n9GNHz3qW9zpRFf2y12fri7tTuk2UuJ/v60fiiabjIX5iUkO/G7a/34x7ObxmqH46E95PyfUAsbgMTU4uNd4QYBv3m/11UB+1a1qfyxr2DgI0R7IblbQkGChVeZ+h4ULOTaF/6CHk7zfRvBQY0wQTl5PXN0jPhudAupGKnNRbnXsgDqar7utjwvW8SYjEg== X-YMail-OSG: pUJugscVM1kgNePik8_gvzw8BCgfn1vuahhClLjPhmq2p0Pn0VRI7u8ihVjAouQ YBuxA7cK4xrt_1TW6.GeUP5CwDiwz1Iw0N5wPm64cD.Z0mbktI8lAQ6Zmt9UIQTjAzaOwX_97jJV _Sx_k1qk.Hwq9UOeRCdDTBB3LmPbb3rnjGUlqLEPhzA5oFq9FfLAxtgUKhRXTsvvTqaH5VMxfcA. Gi6hZkYQ87XjgQfYWcZ9Zcfj1vAnglu1FpS8AIODNW0NTseMFHGC49x9_xfoztVLi3yxp8i0eH7d wgHaeD5EgbHa5X5gmsQa.I_wTG2e1fDIe2COUUgmgpTENtvW_wTe4W2SWYqlBLYODRfYQu3b90Iq _KD8.kCLh0rGmy8e9cFoz1wUdi6BiFqvo7w.hGtpgzrdAoxkzjDcV9wL6QpN36ztGFr8aTZT7N7. 0umYf.ouVwkt0Jq.rggI8.F6EGWP4beM8JkbjNHso_oMddNCvOnleS0KkQUewU1un6_8FaJF4cyb _BE3khWG__L2c5bqvrDYMzOGv7Z6.hvGnx5HohXcmhwF8AvTJUEMbRJlfVcIv8mTMsbQwlRtzUic sG_lsBBQHAXkC_3lvqu6phw1UOkMn56tsGOOPmsAR3LW05VncpJKZi9iCc5U_kDQRwhoo7ymkYDb Qb4VNhXMKSAx4Kpts7CBvgRtM.FdBCU_wFNkCIWi8PACoqD7W2L8qnUMhQ9x1RK5.ShRqCjT5YOY nJ1cCHjCt.UB9LQ4eKwYgU9od8bF_VKlQrMAsbpIDQkcE92ltPmkODXuLXaknwRalfdX2.k4bBvA gemCrsKf0ukitMpDW24BE_0FBfjTqNIgTTExC8sPJgiY5zsrTwuHCml5mh.mbjDw2w0jHFEphjTD GowCyGCFc561q4_0CMJ4DNcQIz0lkr8m3rXGErWbAr4ErMCl1Rognhd3lV3AbJP4cU6V.kAQACnU W461E.twI_XMxcVKD4ruKS6idJgaru.2xak.39BcTgfdP8d0ayRICFL4pgUNnhMwwF_woeFh585W mnBVU89w3x5GIPW.oSxdlBt3HERSCHznByCtMXFOGrTccOAUveosUikIgRaBtBBzYj17nq_rphzQ 4CV4wDreR_pZvkiTr_hkDCr.XeEzCWDcD3FsjvrvBecnbHnefcbQRk3yHmZ5wrtQzlMKxAkDZLix KeYmg2Bctw_2S73cN5211O4M4linPYO5s7k_K7NVt1ai5X8_Ii7fHSJQGnpYiJ4xPiSZ9rdPFKIz wLPJWUrJ5qIHowNITfiy992AsQ9Thgg1fKY2RvBuFNcG8FrTKatI2ybEq8R4pVxQwt0weA8YVO5s Kgh_l.4rRMm74JjWLL9EHbqHFhSnzEXI8NckfbQfc0P5k7Y2Io5o080Vv32NDh9Dbyz1P6cvzsS. ihVSBkLO32UFfP2z9eCW_tKo9GI1ubZHZfk4d805c48Dk_.d78nyeLXg5MjhZE_qE.Ulzx4VKoB9 zMoMZToK5viNrSE1dV6did2yGk2tiLlOnJvlanpNu.rjiqWOPhIRBI9Cx3it..AURPuClHvrHcXm wB_XuwLfMgx051VHBI0FVgXSv9X5YcsAZdXS27Y3qEw4I6F9TypgAuRFIpoxolHx8vNg66M0u6QA 9wT9SjnNT5isGOjyZHEgCi8xHRNyzNQrYqFhiZZa7RO7KCBqbFl_OqpKV0d.aYoGz5tCIfPrEId_ A1atfH8DCifC0Rdv.4YQZktKZkw7f13gc9FCsmQ7PX6jb_f2BwGABufTvzHWA6dLejg9sfXxzskL IBkk7r2fhm2YHbDeHzWoId_OH4x_Ks1LZZ.W0Xop_6WSXgv8RSam87szMcH7j3iMuOvVB0Y3T5Ri aukfz94C1gUusFoAfRDz_1wogkVSloVzF8_731KYreR4LGbAieIlsI2_7fzzlUwDMQbjfiJk3KKd 2UyhaAFX6m5rNAr2UoeN_XnuKt6lU8Z13WNSwn8N3FSYwwB9Bp4Xcqvlcg4o.YLuBv5NDeVVhDFt pJA3aKx1Z81pZw1SrWx_C3Ce1otArzB8POKfch6P7crvxdriVZmyJCCBi2sAgUqReeex5Fexmlb6 5cur2EYNioD.jEPH4PDxifORWK0v7NdoNeSANQzwmeAIFUoF8NIiuTtv3NUYoCVyFdtnTVqORDMl jpGZqO_MWSTE.urYDn4fRHEbiqpCYSsWGmfMT9r7AXFi6kq5DkW.O8quzoh2glNf69wXlSwAhqBn 0n23j4WMJSc6YS8lYVKPFPIFy3_WZw0POXFnrw7f5XoJ8uYm5Dl_Sg1SjMa7efPDXojmKC46c2u0 - X-Sonic-MF: X-Sonic-ID: 8f38454d-a12c-4a7d-940d-a29281bf6744 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Apr 2023 07:35:44 +0000 Received: by hermes--production-ne1-7dbd98dd99-zgnmj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 23fe8ebff53bf8ddba1854cf0e45ed8f; Tue, 25 Apr 2023 07:35:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: current status of zfs block_cloning on CURRENT? Message-Id: <6F5B60BD-C5D2-4145-813D-263C52E05A02@yahoo.com> Date: Tue, 25 Apr 2023 00:35:29 -0700 To: Warner Losh , Current FreeBSD X-Mailer: Apple Mail (2.3731.400.51.1.1) References: <6F5B60BD-C5D2-4145-813D-263C52E05A02.ref@yahoo.com> X-Spamd-Result: default: False [-1.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; SUBJECT_ENDS_SPACES(0.50)[]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4Q5DLq3b7dz3R6n X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote on Date: Tue, 25 Apr 2023 04:30:26 UTC : > On Mon, Apr 24, 2023 at 9:49=E2=80=AFPM Charlie Li = wrote: >=20 > > Charlie Li wrote: > > > Pete Wright wrote: > > >> i've seen a few threads about the block_cloning feature causing = data > > >> corruption issues on CURRENT and have been keen to avoid enabling = it > > >> until the dust settles. i was under the impression that we either > > >> reverted or disabled block_cloning on CURRENT, but when i ran = "zpool > > >> upgrade" on a pool today it reported block_cloning was enabled. = this > > >> is on a system i rebuilt yesterday. > > >> > > > The dust has settled. > > Barely... > > >> i was hoping to get some clarity on the effect of having this = feature > > >> enabled, is this enough to trigger the data corruption bug or = does > > >> something on the zfs filesystem itself have to be enabled to = trigger > > >> this? > > >> > > > The initial problem with block_cloning [0][1] was fixed in commits > > > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > > > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in = commit > > > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data = corruption > > > problem [2][3] was fixed in commit > > > 63ee747febbf024be0aace61161241b53245449e. All were committed = between > > > 15-17 April. > > > > > > [0] = https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > > > [1] https://github.com/openzfs/zfs/pull/14739 > > > [2] https://github.com/openzfs/zfs/issues/14753 > > > [3] https://github.com/openzfs/zfs/pull/14761 > > > > > Given mjg@'s thread reporting further crashes/panics, you may want = to > > keep the sysctl disabled if you upgraded the pool already. > > >=20 > I thought the plan was to keep it disabled until after 14. And even = then, > when it comes back in, it will be a new feature It should never be = enabled. = https://lists.freebsd.org/archives/freebsd-current/2023-April/003514.html had Pawel Jakub Dawidek reporting adding a sysctl vfs.zfs.bclone_enabled to allow the feature to be actually in use in 14, with a default that would not have it in use. (Any cases of previously enable but not "in use" here is wording simplification as I understand: special handling if active from a previous pool upgrade and later activity so that it cleans itself up, or something like that.) Presuming no ability to have the feature actually in use ( so no ability to set vfs.zfs.bclone_enabled ), there also is then the question of reverting the block_cloning related code in the source vs. just blocking its (non-cleanup) activity. Also, there are folks that ended up with block_cloning enabled and a question is what is intended for 14.0-RELEASE for them: Require them to create a new pool that is not upgraded but has the content transfered? Allow them to use the pools in 14.0-RELELASE? I think all 3 of those are showing up in the exchanges that are happening. Sometimes it can be unclear for one or more of those what the status intended is --but they are not fully independent issues. (My wording is likely a simplification in various ways.) =3D=3D=3D Mark Millard marklmi at yahoo.com