>>>>> "re" == Richard Elling <richard.ell...@gmail.com> writes:
re> a well managed system will not lose zpool.cache or any other
re> file.
I would complain this was circular reasoning if it weren't such
obvious chest-puffing bullshit.
It's normal even to the extent of being a best practice to have no
redundancy for rpool on systems that can tolerate gaps in availability
because you can reinstall from the livecd relatively quickly.
re> It is disingenuous to complain about multiple failures
strongly disagree. I'm quite genuine.
A really common and really terrible suggestion is, ``get an SSD, and
put your rpool in one slice and your slog in another.'' If you do
that and lose the SSD, you've lost the whole pool. You cannot recover
with 'zpool clear' or any number of -f -F -FFF flags. This common
scenario doesn't require any multiple failure.
Now, even among those who don't do this, people following your
suggestions will not design their systems realizing the rpool and the
SSD make up a redundant pair. They will not see: you can lose the
rpool and import the pool IFF you have the SSD, and you can lose the
SSD and force-online the pool IFF you have the rpool with the
missing-slog pool already imported to it. They will instead desgin
following the raidz/mirroring failure rules treating slog as
disposable, like you've told them, and this is flat wrong. Hiding
behind fuzzy glossary terms like ``multiple failures'' is useless,
IMHO to the point of being deliberately obtuse.
Besides that, you don't need any multiple failures---all you need to
do is make the mistake of typing the perfectly reasonable command
'zpool export' in the course of trying to fix your problem, and poof,
your whole pool is gone.
A pool that runs fine until you try to export and re-import it, after
which it is permanently lost, is a ticking time bomb. I don't think
it's a good idea to run that way at all because of the flexible tools
one needs to have available for maintenance in a disaster (ex., livecd
of newer version with special import -F rescue-magic in it, WONT WORK.
moving drives to a different controller causing them to have a
different devid, WONT WORK. accumulate enough of these and not only
does your toolkit get smaller and weaker, but you must move slowly and
with great fear because the slightest move can make everything explode
in totally unobvious ways.). If you do want to run this way, as an
absolute MINIMUM, you need to discuss this cannot-import case at
moments like this one so that it can influence people's designs.
It seems if I say it the long way, I get ignored. If I say it the
short way, you dive into every corner case. I don't know how to be
any more clear, so...good luck out there, y'all.
pgplz3pxj4vHy.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
