Darren J Moffat writes:
> >>> You can avoid this by swapping to a zvol, though at the moment this
> >>> requires a fix for CR 6405330. Unfortunately, since one cannot yet dump
> >>> to
> >>> a zvol, one needs a dedicated dump device in this case ;-(
> >> Dedicated dump devices are *always* best, so this is no loss. Dumping
> >> through filesystem code when it may be that code itself which caused the
> >> panic is badness.
> >
> > True, but it adds another complication to the boot disk creation, although
> > it would nonetheless be nice to have this at least as an option. In
> > addition, if the single dump slice isn't mirrored and the disk wedged, you
> > loose the dump completely (though this should be rare). Adding in an SVM
> > mirror if one doesn't need SVM otherwise (as will happen once ZFS boot
> > integrates) certainly isn't atttrative here (and adds another software
> > layer between the dump code and the devices).
>
> The ZFS boot project is fixing that CR so that you can dump to a zvol.
Cool, though I hope you don't talk about CR 6405330 I mentioned above: this
one is just about not adding a zvol used as a swap device during a regular
boot since zvols are created later than swapadd is run. I've contributed a
fix already and Eric Lowe is working to integrate it.
Rainer
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
