|
From: | Seth Goldberg |
Subject: | Re: ZFS on Debian GNU/kFreeBSD |
Date: | Thu, 22 Jul 2010 11:25:08 -0700 (PDT) |
User-agent: | Alpine 2.00 (GSO 1167 2008-08-23) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |