Date: Wed, 19 Apr 2023 00:02:45 +0200 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= <fbl@aoek.com> To: Mark Millard <marklmi@yahoo.com> Cc: Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-ID: <8fecc2d8c2eb471ec70122a7d5fb249d@mail.yourbox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <yourpool> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8fecc2d8c2eb471ec70122a7d5fb249d>