Re: getroot for ZFS without libzfs?

[Zachary Bedell]

On Aug 10, 2011, at 8:22 AM, Robert Millan wrote:
> 2011/8/9 Zachary Bedell <address@hidden>:
>> You'd need to look at all the raw devices to begin with and see which if any 
>> has a ZFS label
> 
> Yes, but how do you know this is the label you wanted?  Consider the
> case where there's more than one pool with this name.

The pool can be identified positively via the guid which is in the labels and 
available via `zpool list -H -o guid <pool name>`.  It's not possible to have 
two pools imported at once with the same name, so getting the root dataset via 
parsing /proc/mounts, /etc/mtab, or /etc/mnttab then going to `zpool list` will 
give you the guid of the root pool definitively.  Then just parse all the 
device labels until you find a label with a matching guid.  (And probably keep 
scanning for all of the devices with that guid to install Grub to all of them 
similar to the MD support, but I'm getting ahead of myself…)

It would also be possible to check the imported status of the pool since a 
conflicted name couldn't be imported normally (though multiple pools available 
via SAN fabric would probably invalidate that).  It may also be possible to 
compare the hostid of the host that has it imported, though I'm not sure it's 
possible to get the hostid reliably without going to libzfs.  There's logic in 
the Linux ZFS driver that diverges from both Solaris and FreeBSD a bit as far 
as how the hostid is calculated from the live system, so that's probably a 
tough option.

Is calling out to zpool as a helper kosher?  The -H flag to zpool pool is 
basically Sun's idea of a public API in that it's intended to output only the 
requested fields with no header information for automated parsing.

>>> The other API that is available to us is /dev/zfs.  But is that device
>>> meant to be used directly?  How stable is this interface?
>> 
>> /dev/zfs is probably less stable than libzfs
> 
> Then I wouldn't use /dev/zfs.  The less stable and standard is the ZFS
> API GRUB uses, the more likely is that one can argue it doesn't fall
> under the "system library" exception.

Definitely agree.  The fact that libzfs is specifically listed as private API 
not intended for linking against also makes me wonder if the syslib exception 
is a concern for that.

> Directly accessing on-disk structures is entirely different, since a
> data structure itself can't be copyrighted.

Right.  And a bonus that the on-disk is well documented by Sun with the 
explicitly stated purpose of interoperability.


Assuming calling out to zpool would be acceptable, I think I'm going to dive in 
this week and see if I can get it running.  The libzfs related autoconf stuff 
is the biggest area that Linux is "special" in, and it would be nice to yank 
that all out.

-Zac