On Apr 18, 2023, at 15:02, José Pérez <f...@aoek.com> wrote: > 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.
I was not really worried about the no-zpool-upgrade/disabled case. I was worried about "enabled" vs "active" as the transition enabled -> active is automatic based on activity. But there is overall disabled vs. enabled vs. active for the block_cloning feature so I mentioned all 3. >>> 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 (*). "Not being there" vs. "disabled" has some context to it. I worded based on the way my context shows things. My example context has: # zpool get all zroot | grep compat zroot compatibility openzfs-2.1-freebsd local which explains the particular list of disabled features reported below. (It is a "never had zpool upgrade" context as well.) # zpool get all zroot | grep disabled zroot feature@edonr disabled local zroot feature@zilsaxattr disabled local zroot feature@head_errlog disabled local zroot feature@blake3 disabled local zroot feature@block_cloning disabled local so "not be there" seems to mean "disabled" as zpool presents things based on compatibility. Just to see the command you listed fully but in my type of context: # zpool get feature@block_cloning zroot NAME PROPERTY VALUE SOURCE zroot feature@block_cloning disabled local # zpool version zfs-2.1.99-FreeBSD_g431083f75 zfs-kmod-2.1.99-FreeBSD_g431083f75 (Those are software versions, not properties of specific pools.) I'll note that I see: # zpool get feature@JUNKNAME zroot # So features that the software does not have in its list of possibilities get an empty result. > unaffected_machine# zpool get feature@block_cloning zroot > unaffected_machine# That is the same sort of output as in my feature@JUNKNAME test above. It is not clear from what is presented that the context had block_cloning in its list of possibilities. In my normal environment (that still predates the import of the openzfs update), I get the same sort of result for feature@block_cloning as you show above. > As said, if the feature has been enabled but no calls to > copy_file_range() occurred, the pool is also sane. A the time but more activity can change the status because copy_file_range() could be called. So I expect that the following step is relvant to avoid ending up with block_cloning becoming active: QUOTE When in single user mode set compression property to "off" on any zfs active dataset that has compression other than "off" and the sync property to something other than "disabled". END QUOTE > To summarize: > no feature -> sane > feature "enabled" -> sane > feature "active" -> might not be sane > > BR, > > (*) as per this bug. === Mark Millard marklmi at yahoo.com
