>>>>> "t" == Tim <[EMAIL PROTECTED]> writes:
t> Uhh, yes. There's more than one post here describing how to
t> set what the system does when the pool is in a faulted
t> state/you lose a drive. Wait, panic, proceed.
(a) search for it, try it, then report your results. Don't counter a
reasonably-designed albeit quick test with stardust and fantasy
based on vague innuendos.
(b) ``ALL of the above are settings that can be changed.'' Please
tell me how to fix ``ALL'' my problems, which you claim are all
fixable without enumerating them. I will:
1. panic on exporting pool
2. 'zpool import foolpool' coredumps
3. pools backed by unavailable iSCSI targets and stored in
zpool.cache prevent bootup
4. WARNING: ZFS replay transaction error 30, dataset boot/usr, seq 0x134c,
txtype 9
5. disappearing, reappearing /usr/export/t00 (the backing for the
file vdev was another ZFS pool, so this is also a ZFS problem)
Yeah, I'm pressing the issue. But I'm annoyed because I gave the
question an honest go and got a clear result, and instead of repeating
my test as you easily could, you dismiss the result without even
reading it carefully. I think it's possible to give much better
advice by trying the the thing out than by extrapolating marketing
claims.
t> I've read of more than one person here that has worked with a
t> Sun Engineer to manually re-create the metadata.
(a) not in this situation, they didn't. The loss was much less
catastrophic than a whole vdev---in fact it wasn't ever proven
that anything was lost at all by the underlying storage. I think
the pool may also have been simpler structure, like a
single-device vdev exported as a LUN from a SAN.
(b) that's not the same thing as *backline*, whatever that is.
(c) that's pretty far short of ``if you get lucky enough ... you might
be able to survive.'' My claim: there is zero chance of importing
the pool in the normal, supported way after this failure scenario.
(d) I don't think the OP had in mind counting on support from Sun
engineering when you responded by suggesting an unredundant pool
with copies=2 might suit his needs.
pgpay2xwP8YSt.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
