[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: Fri, 23 Jul 2010 13:26:49 -0700 (PDT)
User-agent: Alpine 2.00 (GSO 1167 2008-08-23)

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

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

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


reply via email to

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