[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ZFS on Debian GNU/kFreeBSD
Re: ZFS on Debian GNU/kFreeBSD
Fri, 23 Jul 2010 13:26:49 -0700 (PDT)
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
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