Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

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