From nobody Tue Apr 18 22:02:45 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 4Q1HwZ6y26z45l8t for ; Tue, 18 Apr 2023 22:02:54 +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 4Q1HwZ0jyZz3DBQ for ; Tue, 18 Apr 2023 22:02:54 +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 33IM2oVa006351; Wed, 19 Apr 2023 00:02:50 +0200 (CEST) (envelope-from fbl@aoek.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aoek.com; s=mailbox; t=1681855370; bh=WjwWZ6M07ljOOkOqLULXQ2XVMezkEQizb6QbEMBwICs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=R+9ll0KjV1dodQ/ptkp8BGPeiFZbj2r4IHNa/0DdNaUzsSe0QbWNylDF1sKprqY5A NN+hde+7dXWqy2FrSD57AYC7i1YP0KRs+VioRdSDT1PfKO712FA6qF9lOz5e3wzlkt 04vmxhDToVbiSZbwn/UJGG1VmI5qI0l1YB4fl+CvFrKswSqxycL6AL4GkPJ+R9soMe xIwaW/xNb/RCCUvpsdxjYVdRd1kvhPRntRqN6OG3i4lcZJjQr4M41eSWCJegtz8o8z CGWUEcX40cqgtUw+7th79AgaDWyBKSZFNv+sjqYitPgOqELOsgg4UH5XGxmhOazyyr xJH+/UN3zUKUA== 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: Wed, 19 Apr 2023 00:02:45 +0200 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= To: Mark Millard Cc: Current FreeBSD Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-Reply-To: <963B0620-5342-4EC3-AA54-52DDD70D9E3D@yahoo.com> References: <963B0620-5342-4EC3-AA54-52DDD70D9E3D.ref@yahoo.com> <963B0620-5342-4EC3-AA54-52DDD70D9E3D@yahoo.com> Message-ID: <8fecc2d8c2eb471ec70122a7d5fb249d@mail.yourbox.net> X-Sender: fbl@aoek.com User-Agent: Roundcube Webmail/1.2.0 X-Rspamd-Queue-Id: 4Q1HwZ0jyZz3DBQ 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-18 21:37, Mark Millard escribió: >> In this case it does because the value is "active". If it's "enabled" >> you do not need to do anything. > > Well, if block_cloning is disabled it would not become active. [...] > So, in progressing past the vintage that corrupt zfs data, > one could end up with block_cloning enabled in the process. You still have to willingly issue the command zpool upgrade so you might not just end up with the feature enabled by running this or that kernel, that's why I suggested step 0: verify if you are the worst case scenario before you begin. >> Boot in single user mode and check if your pool has block cloning in >> use: >> # zpool get feature@block_cloning zroot >> NAME PROPERTY VALUE SOURCE >> zroot feature@block_cloning active local >> >> In this case it does because the value is "active". If it's "enabled" >> you do not need to do anything. If you did not upgrade the pool, the feature would just not be there and the pool is sane (*). unaffected_machine# zpool get feature@block_cloning zroot unaffected_machine# As said, if the feature has been enabled but no calls to copy_file_range() occurred, the pool is also sane. To summarize: no feature -> sane feature "enabled" -> sane feature "active" -> might not be sane BR, (*) as per this bug. -- José Pérez