Date: Sat, 11 Oct 2008 05:30:22 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Danny Braniss <danny@cs.huji.ac.il> Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick <koitsu@freebsd.org>, Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> Subject: Re: continuous backup solution for FreeBSD Message-ID: <200810111230.m9BCUMxp057391@apollo.backplane.com> References: <200810091411.m99EB0Vo007538@lurza.secnetix.de> <20081010023428.87556dt18ejyzf48@mail.ispro.net> <20081009200641.60d0b236@bhuda.mired.org> <48EF5052.2000707@ispro.net> <20081010144111.GA34609@icarus.home.lan> <20081010112952.52b8209b@bhuda.mired.org> <20081010154249.GA35859@icarus.home.lan> <20081010122228.355c2c3e@bhuda.mired.org> <E1Koboa-000CyO-8l@cs1.cs.huji.ac.il> <20081011104409.GA58698@icarus.home.lan> <E1KocK0-000DEX-PV@cs1.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
:> boot2/loader does not speak ZFS -- this is why you need the /boot UFS2
:> partition. This is an annoyance.
:>
:> For the final "stage/step", vfs.root.mountfrom="zfs:mypool/root" in
:> loader.conf will cause FreeBSD to mount the root filesystem from ZFS.
:> This works fine.
:
:so the answer is:
: yes, if you have only one disk.
: no, if you have ZFS over many disks
:
:because I see no advantage in the springboard solution where ZFS is used to
:cover several disks.
:
:I'm asking, because I want to deploy some zfs fileservers soon, and so
:far the solution is either PXE boot, or keep one disk UFS (or boot off a USB)
:Today's /(root+usr) is somewhere between .5 to 1Gb(kernel+debug+src),
:and is readonly, so having 1 disk UFS seems to be a pitty.
:
:danny
I think it is is perfectly acceptable to have a /boot + ZFS style
solution, where /boot is a small ~256M UFS filesystem that the
system actually boots from (containing only the kernel, modules,
loader.conf, etc), and ZFS is the root filesystem. In a running
system /boot would be mounted under the ZFS root.
All I needed was a line in /boot/loader.conf to tell the kernel
where the root FS was. In my case, I pointed it at HAMMER.
vfs.root.mountfrom="hammer:ad0s1d"
This gives you the flexibility of being able to have as complex a
root FS as you want.
Filesystem 1K-blocks Used Avail Capacity Mounted on
HAMMER_ROOT 36388864 9789440 26599424 27% /
/dev/ad0s1a 257998 100074 137286 42% /boot
/pfs/@@-1:00001 36388864 9789440 26599424 27% /usr
/pfs/@@-1:00003 36388864 9789440 26599424 27% /var
/pfs/@@-1:00006 36388864 9789440 26599424 27% /tmp
/pfs/@@-1:00007 36388864 9789440 26599424 27% /home
/pfs/@@-1:00005 36388864 9789440 26599424 27% /var/tmp
/pfs/@@-1:00002 36388864 9789440 26599424 27% /usr/obj
/pfs/@@-1:00004 36388864 9789440 26599424 27% /var/crash
procfs 4 4 0 100% /proc
The /boot is small enough that it can be dealt with numerous ways,
including simple duplication if you have multiple disks (have a
adXs1a on two drives). And if you were really that worried you
could put /boot on a SSD. Frankly, anything that has approximately
the same MTBF as the motherboard itself is suitable, there's really
no point trying to make /boot disk-redundant when the motherboard
and memory aren't redundant. If you have more then one HD connected
to the system, and you want boot redundancy, then you also likely
have the $$ to purchase a tiny SSD for your /boot.
The big problem trying to boot from a completely generic FS setup
is that it tends to severely limit your options. You might want to
have more flexibility in your root filesystem that you could otherwise
accomodate if /boot were integrated into it.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200810111230.m9BCUMxp057391>