From nobody Mon Apr 17 12:28:40 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 4Q0RDc3Nm2z45qG0 for ; Mon, 17 Apr 2023 12:28:48 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from mail.yourbox.net (mail.yourbox.net [IPv6:2001:41d0:1:767d::1]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.yourbox.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q0RDc0Ytnz3NHD; Mon, 17 Apr 2023 12:28:47 +0000 (UTC) (envelope-from fbl@aoek.com) Authentication-Results: mx1.freebsd.org; none Received: from mail.yourbox.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail.yourbox.net (8.17.1/8.17.1) with ESMTP id 33HCSjL5029378; Mon, 17 Apr 2023 14:28:45 +0200 (CEST) (envelope-from fbl@aoek.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aoek.com; s=mailbox; t=1681734526; bh=VKyPY4x1en3p34OfbfXvO2HmGbDGxO+BCRv3U4VFkVM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=NTC4+qBl7kvQg2+0K7sbzrRJapdZqitnFZdRbqG/T1kZJcYoAsVphpk3+BsjumqFN dyAiy8YBaTmMaWcawRggXSTw6tyR5r1mKaw1QIOFVBC+iN8/2JxaYpUzENuvFsqWLZ gYakDm6fQajqjCETZAzsGR8opjMMieQn6iFRbsQzuR4oWbCQcqfzP2ofuhtnJ1MCnk oFwmPQUqNvNT4/ohK8bTvgsjBGJYknIh1VT5PwayZTNlZld0FNkq7pzyezF6inzvT2 QsE8Zl4Qzd8z0op00h5d1U3EmuwCVvzQj403ID78wOIVAb55EFNMbC/LY3dea5skKq GnZ5ZJmtaC/uw== 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 17 Apr 2023 14:28:40 +0200 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= To: Pawel Jakub Dawidek Cc: freebsd-current@freebsd.org Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-Reply-To: <0164e42a-e7cd-a1e8-295c-21f414edf67b@dawidek.net> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> <6792aded-6e2e-a118-259d-0df0f80c361c@smeets.xyz> <80ea8a67-9b64-c723-6d97-21cfa127ae43@dawidek.net> <01430095-33a3-a949-3772-2ec90b4c3fe6@dawidek.net> <0164e42a-e7cd-a1e8-295c-21f414edf67b@dawidek.net> Message-ID: X-Sender: fbl@aoek.com User-Agent: Roundcube Webmail/1.2.0 X-Rspamd-Queue-Id: 4Q0RDc0Ytnz3NHD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N El 2023-04-17 12:43, Pawel Jakub Dawidek escribió: > On 4/17/23 18:15, Pawel Jakub Dawidek wrote: >> There were three issues that I know of after the recent OpenZFS merge: >> >> 1. Data corruption unrelated to block cloning, so it can happen even >> with block cloning disabled or not in use. This was the problematic >> commit: >> >>     https://github.com/openzfs/zfs/commit/519851122b1703b8445ec17bc89b347cea965bb9 >> >> It was reverted in 63ee747febbf024be0aace61161241b53245449e. >> >> 2. Data corruption with embedded blocks when block cloning is enabled. >> It can happen when compression is enabled and the block contains >> between 60 to 112 bytes (this might be hard to determine). Fix exists, >> it is merged to OpenZFS already, but isn't in FreeBSD yet. >>     OpenZFS pull request: https://github.com/openzfs/zfs/pull/14739 >> >> 3. Panic on VERIFY(zil_replaying(zfsvfs->z_log, tx)). This is >> triggered when block cloning is enabled, the sync property is set to >> disabled and copy_file_range(2) is used. Easy fix exists, it is not >> yet merged to OpenZFS and not yet in FreeBSD HEAD. >>     OpenZFS pull request: https://github.com/openzfs/zfs/pull/14758 >> >> Block cloning was disabled in >> 46ac8f2e7d9601311eb9b3cd2fed138ff4a11a66, so 2 and 3 should not occur. > > As of 068913e4ba3dd9b3067056e832cefc5ed264b5cc all known issues are > fixed, as far as I can tell. > > Block cloning remains disabled for now just to be on the safe side, > but can be enabled by setting sysctl vfs.zfs.bclone_enabled to 1. > > Don't relay on this sysctl as it will be removed in 2-3 weeks. Hi Pawel, thank you for your reply and for the fixes. I think there is a 4th issue that needs to be addressed: how do we recover from the worst case scenario which is a machine with a kernel > 2a58b312b62f and ZFS root upgraded with block cloning enabled. In particular, is it safe to turn such a machine on in the first place, and what are the risks involved in doing so? Any potential data loss? Would such a machine be able to fix itself by compiling a kernel, or would compilation fail and might data be corrupted in the process? I have two poudriere builders powered off (I am not alone in this situation) and I need to recover them, ideally minimizing data loss. The builders are also hosting current and used to build kernels and worlds for 13 and current: as of now all my production machines are stuck on the 13 they run, I cannot update binaries nor packages and I would like to be back online. Whatever the fixing procedure, it shall be outlined in the UPDATING document. Thank you. BR, -- José Pérez