Re: ZFS on Debian GNU/kFreeBSD

[Seth Goldberg]

Quoting Robert Millan, who wrote the following on Fri, 23 Jul 2010:

> 2010/7/22 Seth Goldberg <address@hidden>
> > > 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.
>
> What are you currently implementing? I just want to make sure I don't
> duplicate existing work.

 Sure -- The code I currently have in getroot.c and util.c is ugly (it's 
filesystem-aware), because of the disparity in the design as you mentioned. 
The code currently stat()s the given file, gets the st_dev and uses that to 
correlate the filesystem with the major/minor available via getextmntent(). 
It then looks at mnt_special (which is the zpool/zfs name) and looks up the 
pool via libzfs's zpool_get_physpath() (which only returns one device, 
incidentally, which is fine for now for testing, but is not good enough for a 
fault-tolerant configuration).  I also made modifications to 
grub_make_system_path_relative_to_its_root() to adapt the pathname passed in 
to Vladimir's current zfs design (/<fsname>@/<path>).  I now have working 
grub-probe and grub-setup (For Solaris's uses, I'm modifying grub-setup to use 
the boot slice in a Solaris partition instead of the zfs filesystem slice 
(because that's where our tools look for the boot loader on disk). Other OSes 
that use zfs can simply embed core into the zfs boot block area (which is over 
3M in size).

I like the idea of having the zfs stuff conform to the abstraction (though I 
think it's unique in its ability to use different-size disks, arbitrary 
partitions, etc, as part of its pool, so assuming that's workable in the GRUB2 
design, I'd much rather see (<poolname>)/address@hidden/<path> at the 
top-level than have to deal with the disk partitions individually).  Since 
it's not an abstraction today, the code to deal with it has been a bit ugly -- 
I'm all for clean design here.


> > > 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).
> >
> >  [...] 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.
>
> Ah, I understand you now. You want to take advantage of ZFS' fault-tollerancy
> for boot blocks. I'm not sure this would make sense, because we have to give
> up at some point (e.g. boot.img can't benefit from this), so we're just moving
> the line. In any case, I just want the basic functionality to work and it's not

 Actually, that's not true.  Even boot.img can benefit if the system firmware 
cannot read from the disk (then fails over to the next bootable device in the 
device list -- and that's exactly what we do today on BIOS systems, and it 
works well).

 --S