Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

["Ricardo M. Correia" <Ricardo.M.Correia@Sun.COM>]

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