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

On Apr 18, 2023, at 15:02, José Pérez <fbl@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