[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ZFS on Debian GNU/kFreeBSD
Re: ZFS on Debian GNU/kFreeBSD
Thu, 22 Jul 2010 11:25:08 -0700 (PDT)
Alpine 2.00 (GSO 1167 2008-08-23)
Quoting Robert Millan, who wrote the following on Thu, 22 Jul 2010:
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
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
That's how I'm implementing it, though libzfs is technically an uncommitted
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).
Re: ZFS on Debian GNU/kFreeBSD, Robert Millan, 2010/07/23
- ZFS on Debian GNU/kFreeBSD, Tuco, 2010/07/21
- Re: ZFS on Debian GNU/kFreeBSD, Vladimir 'φ-coder/phcoder' Serbinenko, 2010/07/21
- Re: ZFS on Debian GNU/kFreeBSD, Robert Millan, 2010/07/23
- Re: ZFS on Debian GNU/kFreeBSD, Seth Goldberg, 2010/07/23
- Re: ZFS on Debian GNU/kFreeBSD, Vladimir 'φ-coder/phcoder' Serbinenko, 2010/07/28
- Re: ZFS on Debian GNU/kFreeBSD, Robert Millan, 2010/07/28