Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

[Eric Sandeen <sandeen@redhat.com>]

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
> 
>