Hi Eric, On Seg, 2009-04-06 at 13:13 -0700, Eric Sandeen wrote: > Can you perhaps just chime in on these bugs & ask? you speak zfs better > than I do... > > https://bugzilla.redhat.com/show_bug.cgi?id=494070 > https://bugzilla.redhat.com/show_bug.cgi?id=490795 Sorry for taking a while to get back to you. I've just looked at these bugs and everything seems to make more sense now. Those partitions are actually Solaris partitions, which contain their own partition table inside. So in bug 494070, the /dev/sda2 partition is internally subdivided into what Solaris calls "slices" (which are similar to partitions) and then the root ZFS pool/filesystem is stored inside one of these slices. So in fact, the ZFS pool is not directly in /dev/sda2, it's somewhere inside it. This is why the ZFS magic numbers don't seem to be in the right place. These slices don't seem to be visible to that Linux system, which I suspect is due to the kernel not being compiled with Solaris partition table support. If it were, other partitions (including the ZFS one) would show up (if my assumption is correct). So from looking at the libblkid magic offsets, it seems that ext3 magic value is stored between 1K-2K, which means that it will fall into the boot slice, not in the ZFS slice. So AFAICS this bug doesn't have anything to do with ZFS, i.e., the same thing would happen if the root filesystem of the OpenSolaris installation was UFS. It'd be nice if OpenSolaris zeroed the boot slice when it is installed, but on the other hand, should the Anaconda installer fail just because it can't mount a (possibly corrupted/leftover) filesystem? I can file a bug for OpenSolaris if you feel strongly about this. Thanks, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
