On Thu, Nov 20, 2008 at 5:37 PM, Miles Nordin <[EMAIL PROTECTED]> wrote:
> >>>>> "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. I gave you a the PSARC. > > 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. > Which is why I told him not to do it, and that his chances were slim...
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
