Quoting "Patrick M. Hausen" <p...@hausen.com> (from Wed, 9 Nov 2022 21:02:52 +0100):

Hi,

Am 09.11.2022 um 20:58 schrieb Alexander Leidinger <alexan...@leidinger.net>:

Quoting "Patrick M. Hausen" <p...@hausen.com> (from Wed, 9 Nov 2022 20:49:37 +0100):

Hi,

Am 09.11.2022 um 20:45 schrieb Alexander Leidinger <alexan...@leidinger.net>: But "zpool set feature@edonr=enabled rpool" (or any other feature not in the list we talk about) would render it unbootable.

Sorry, just to be sure. So an active change of e.g. checksum or compression algorithm might render the system unbootable but a zpool upgrade never will? At least not intentionally? ;-)

If you mean "zpool upgrade", then no (modulo bugs). OpenZFS uses the feature flags instead of zpool upgrade.

I know about feature flags and all my pools are recent enough to have them.

Yet, I made it a habit to whenever I see this message:

-----------
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(7) for details.
-----------

to do a "zpool upgrade" after some time of burn in followed by an update of the
boot loader.

I desire to know if that is in fact dangerous.

Ugh. This changed. It is indeed dangerous now. I just tested it with a non-root pool which didn't had all flags enabled. "zpool upgrade <pool>" will now enable all features.

I remember that it wasn't in the past and I had to enable the feature flags by hand. I don't know if a pool with bootfs set is behaving differently, but I consider testing this with a real rpool to be dangerous.

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Attachment: pgp55U6MDTOxF.pgp
Description: Digitale PGP-Signatur

Reply via email to