Feature request: way to suppress 'features not enabled' warning in zpool status

[GregorKopka]

This 'nag screens' in zpool status

status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(5) for details.

and

status: The pool is formatted using a legacy on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on software that does not support
        feature flags.

are extremely annoying: While the warning might be interesting to some, I know that there are unactivated features on some of my pools (not by accident).

I would like to be able to suppress this on a per-pool level, for example throught a property 'featurewarning=disabled'.

[FingerlessGlov3s]

Shame this isn't a setting :-(

[carlreinke]

Or maybe a new option zpool upgrade --suppress which would set the disabled features to a new suppressed state, which is just like disabled except that you don't get an upgrade nag and zpool upgrade skips enabling them in the future.

[tuxick]

I 'fixed' it for now by simply removing the UNAVAIL from zfs_health.sh. Maybe making this configurable in the script is the simplest solution.

[mufunyo]

Honestly, zpool clear should just clear this status until the user tries to enable a feature that is unsupported by the pool version, at which point zpool upgrade can be suggested again.

[ghost]

Maybe "features:" and "format:" can be additional sections only shown with -v output?

[mcdonc]

Maybe retain the current behavior but implement a flag on zpool clear like --suppress-unsupported that sets the feature property states to a new value, let's say suppressed.

Let's imagine that two features feature@project_quota, and feature@userobj_accounting are disabled, causing this warning (I use these as examples because this is the current state that is necessary to share a pool between Linux and Mac OS X).

zpool get might show something like

NAME  PROPERTY               VALUE                  SOURCE
z     feature@project_quota  disabled                 local
z     feature@userobj_accounting  disabled                 local

And zpool status before zpool clear --suppress-unsupported might show this:

pool: myzpool
state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Either a) enable all features using 'zpool upgrade'; once this is done,
        the pool may no longer be accessible by software that does not support
        the features or b) suppress this warning via 'zpool clear --suppress-unsupported';
        the features will continue to be disabled but this warning will be suppressed.
        See zpool-features(5) for details.
scan: scrub repaired 0B in 0 days 04:55:52 with 0 errors on Sun Apr 12 05:19:55 2020
config:
...

After zpool clear --suppress-unsupported, zpool status:

pool: myzpool
state: ONLINE
scan: scrub repaired 0B in 0 days 04:55:52 with 0 errors on Sun Apr 12 05:19:55 2020
config:
...

And zpool get would show:

NAME  PROPERTY               VALUE                  SOURCE
z     feature@project_quota  suppressed                 local
z     feature@userobj_accounting  suppressed                 local

Of course you could do it manually via zpool set too.

[mcdonc]

I heard @allanjude mention this in a leadership meeting, maybe he can weigh in on the relative viability of the suggestions proposed here and/or give an alternate.

[mufunyo]

I disagree about retaining the status unless the user clears with a special suppression flag. The whole problem of this message in the first place is it encourages the user to perform a completely unnecessary pool upgrade, putting the pool at risk and limiting compatibility. Users should be taught to be conservative and only perform upgrades if they really want or need a new feature. "If it ain't broke, don't fix it."

[allanjude]

This is related to the talk Josh Paetzel is giving at the OpenZFS Developer summit as well (about making zpool create --compat=openzfs2.0 etc)

[mcdonc]

I disagree about retaining the status unless the user clears with a special suppression flag. The whole problem of this message in the first place is it encourages the user to perform a completely unnecessary pool upgrade, putting the pool at risk and limiting compatibility. Users should be taught to be conservative and only perform upgrades if they really want or need a new feature. "If it ain't broke, don't fix it."

Sounds reasonable that zpool clear without flags should do this.

[allanjude]

I disagree about retaining the status unless the user clears with a special suppression flag. The whole problem of this message in the first place is it encourages the user to perform a completely unnecessary pool upgrade, putting the pool at risk and limiting compatibility. Users should be taught to be conservative and only perform upgrades if they really want or need a new feature. "If it ain't broke, don't fix it."

Sounds reasonable that zpool clear without flags should do this.

I don't think zpool clear is a good choice here, it has too many other side effects (reset error counters, attempt to re-open any faulted devices, etc).

It has the same issue as the force flag in many ZFS commands, it ends up meaning multiple things, and you can't select just the one thing you want.

[behlendorf]

This functionality was added with the new compatibility property starting with the 2.1.0 release

.https://github.com/openzfs/zfs/releases/tag/zfs-2.1.0