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
