From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 12:30:35 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 278FE1065695; Sat, 11 Oct 2008 12:30:35 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id DE51E8FC1C; Sat, 11 Oct 2008 12:30:34 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m9BCUMdm057392; Sat, 11 Oct 2008 05:30:22 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m9BCUMxp057391; Sat, 11 Oct 2008 05:30:22 -0700 (PDT) Date: Sat, 11 Oct 2008 05:30:22 -0700 (PDT) From: Matthew Dillon Message-Id: <200810111230.m9BCUMxp057391@apollo.backplane.com> To: Danny Braniss 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> <20081011104409.GA58698@icarus.home.lan> Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , Mike Meyer Subject: Re: continuous backup solution for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2008 12:30:35 -0000 :> 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