[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ZFS on Debian GNU/kFreeBSD

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)


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
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

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]