Ricardo M. Correia wrote: > 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). It actually is compiled with that... but then we didn't look at /proc/partitions (the kernel's view) in the bug but rather fdisk output, which probably doesn't understand this at all. > 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. ok, makes sense. (maybe blkid should recognize sda2 as being this special sort of partition and stop there...) > 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? Generally, no; and anaconda now will not fail if the mount simply fails. But if the mount attempt results in a kernel oops there's not much anaconda can do... the filesystem that attempts the mount should be robust enough to not oops as well, of course... > I can file a bug for OpenSolaris if you feel strongly about this. Well, it's always nice to be able to recognize a partition; blkid just can't do this reliably if some tools leave old signatures lying around. So zeroing it out would be the "polite" thing to do in any case. :) Thanks, -Eric > 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
