Re: getroot for ZFS without libzfs?

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 11.08.2011 03:04, Zachary Bedell wrote:
> 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,
If you can't import 2 pools with same name in the same time then it's a
bug. It's like not being able to mount 2 disks with same label. And so
as such I expect it to be fixed in future and so I don't rely on this.

> (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…)
>
This would be inappropriate. Install is done to the disk, not to FS. So
if user tells to install to one disk, you have to obey, not guess what
user might have wanted.
> 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).
The status of the pool in on-disk structures may be "IMPORTED" even if
the pool currently isn't. For instance FreeBSD keeps the state to
"IMPORTED" on shutdown and so it would appear as imported if booted into
another OS.
>   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.
>
and unreliable as well.
> Is calling out to zpool as a helper kosher?
English translation of "kosher" ("כשר") is "appropriate". Why not stick
to English?
>   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.
But probably using unusual symbols in zpool names will make the parsing
go haywire anyway.
@Seth: any comment on what Sun considers a public API?
>>
>> 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.
We don't need system library exception to read /dev/zfs. It's not a
library but a way to speak with kernel which is definitely interprocess
communication.
>> 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
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature