[chaostheo]

Yes, without the auto-survive of a power outage zfs will never be accepted by redhat whatever the zfs license is look like in the future, still this simplest thing can bring lots of headache and pain even zfs designed zil and slog but what it's good for when you google cannot import pool ... ?!

[toast0]

You're wanting to take the drives out of a machine that lost power and import the pool somewhere else right? I've not done this, but the man page[1] for zpool-import shows -f and -F which would seem to address this use:

> -f Forces import, even if the pool appears to be potentially active.

> -F Recovery mode for a non-importable pool. Attempt to return the pool to an importable state by discarding the last few transactions. Not all damaged pools can be recovered by using this option. If successful, the data from the discarded transactions is irretrievably lost. This option is ignored if the pool is importable or already imported.

Do those not actually work? There's also zdb(8) if you want to debug a pool, which maybe is useful for recovery, but probably takes a lot of learning to actually be useful. I have about one unclean shutdown per zfs host every 3 years, when its ups battery has worn out and there's a utility power failure, and it's always come back up without intervention, but my write rate is very low.

It's been in the manpage since forever, this one dated 2006 also has -f (but not -F) [2]

[1] https://man.freebsd.org/cgi/man.cgi?query=zpool-import [2] https://man.freebsd.org/cgi/man.cgi?query=zpool&apropos=0&se...

[doublepg23]

I could see a case of extreme hardware failure causing issues but you can use the “force” flag to import a pool that’s been improperly exported.