Date: Fri, 27 Feb 2009 19:21:15 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: freebsd-stable@freebsd.org Subject: Re: ZFS root File System Message-ID: <200902280321.n1S3LFxR018622@apollo.backplane.com> References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> <49A84B63.5080903@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
My experience with one of our people trying to do the same thing
w/ HAMMER... we got it working, but it is not necessarily cleaner.
I'd rather just boot from a small UFS /boot partition on 'a' (256M
or 512M), followed by swap on 'b', followed by the big-ass root
partition on 'd' using your favorite filesystem.
The boot code already pretty much handles this state of affairs, one only
needs:
(1) To partition it this way.
(2) Add line to /boot/loader.conf pointing the kernel at the actual root,
e.g. (in my case):
vfs.root.mountfrom="hammer:ad6s1d"
(3) Adjust sysctl kern.bootfile in e.g. /etc/sysctl.conf. Since the
boot loader thinks the kernel is on / instead of /boot (because
/boot is the root from the point of view of the bootloader),
it might set this to "/kernel" instead of "/boot/kernel". So
you may have to override it to make crash dumps and name lists
work properly.
(4) Add a mount for the little /boot partition in /etc/fstab.
Trying to create one large root on 'a' puts the default spot for swap
on 'b' at the end of the disk instead of near the beginning. The end
of the disk (closer to the spindle) is a bad place for swap. Having
a small /boot partition there instead retains the ordering and puts the
swap where it is expected to be.
# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad6s1d 193888256 1662976 192225280 1% /
/dev/ad6s1a 257998 110896 126464 47% /boot
--
In anycase, if RAID is an issue the loader could always be adjusted to
look for a boot partition on multiple disks. One could then have a /boot
on two independant disks, or even operate it as a soft-raid-mirror. It
seems less of an issue these days since someone with that sort of
requirement who isn't already net-booting can just pop in a SSD for
booting which will have approximately the same or better MTBF as the
motherboard electronics.
The problem we face with HAMMER is related to the boot loader not being
able to run the UNDO buffer (yet), so it might not be able to find
the kernel after a crash. That and the inconvenient place swap ends up
at.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902280321.n1S3LFxR018622>