Re: ZFS on Debian GNU/kFreeBSD

[Seth Goldberg]

Hi,

Quoting Robert Millan, who wrote the following on Thu, 22 Jul 2010:

> Hi,
>
> This has been on my radar for a while now, I'll have a look at it
> (today I start my vacation and have some spare time (but don't hold
> your breath...)).

  Nice to see you around again.  I didn't know you were doing anything with 
the zfs module :).

> 2010/7/21, Seth Goldberg <address@hidden>:
> > The main problem is that the st_dev that you'll get from a call to stat() of
> > a file on a ZFS filesystem won't match the major/minor of any device in /dev
> > (at least on Solaris).  You have to look deeper to figure out the pool name,
> > then query the pool to figure out its devices.
>
> I guess the API exported by libzfs can serve for this?  But first, I
> have some concern about zfs.mod, I'll write a detailed mail about that
> later.

  That's how I'm implementing it, though libzfs is technically an uncommitted 
interface.

> > And if you're REALLY good,
> > you'd invoke grub-setup for each member of a root pool mirror :).
>
> Uhm this sounds wrong, grub-setup isn't meant to handle filesystems
> (it does something like you describe for RAID1, but only because it
> can rely on the storage backend being 1:1).

 zfs is rather unique in this respect -- it's sorta like a filesystem but, 
really, it's pool-based, and the right thing to do is to update the boot 
blocks on all mirrors of the root pool to ensure they stay in synch.  When you 
invoke grub-setup (at least on Solaris), you'll pass it the boot slice (when 
used with a Solaris partition (the sunpc partmap).  When using it with GPT, 
you'll pass it the GPT ZFS partition (into which the core image is embedded on 
BIOS systems -- UEFI is not an issue, since the ESP is used).

 Yes, it's true that the disks used for the mirror can be different, and that 
would require grub-setup to write the boot and core image with different 
embedded information, hence the extra points for that ;).  To be truly 
fault-tolerant, if we're booting from a zfs pool, there must be an embedded 
config file that searches for a (non-faulted) root device from the pool's 
mirrors as well.  Separate invocations for each device in the root pool mirror 
are fine, though.

 BTW, I've run into a similar issue (comparing major/minors) in updating 
grub-probe to deal with zfs -- grub_make_system_path_relative_to_its_root() 
compares st_dev with the st_dev's of each path component.  This won't work on 
ZFS either because GRUB files are stored in the top-level filesystem and 
because the root filesystem (for the purposes of GRUB2's $root) is a different 
filesystem than the top-level filesystem.  GRUB2 was never designed to deal 
with this kind of disparity (even at the RAID level).

 --S