From owner-freebsd-questions@FreeBSD.ORG Sat Feb 19 20:07:32 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 455101065672 for ; Sat, 19 Feb 2011 20:07:32 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id 007DE8FC0A for ; Sat, 19 Feb 2011 20:07:31 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id p1JKCKnP038248 for freebsd-questions@freebsd.org; Sat, 19 Feb 2011 14:12:20 -0600 (CST) Date: Sat, 19 Feb 2011 14:12:20 -0600 (CST) From: Robert Bonomi Message-Id: <201102192012.p1JKCKnP038248@mail.r-bonomi.com> To: freebsd-questions@freebsd.org In-Reply-To: Subject: Re: ZFS-only booting on FreeBSD X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 20:07:32 -0000 > Date: Sat, 19 Feb 2011 10:35:35 -0500 > From: Daniel Staal > Subject: Re: ZFS-only booting on FreeBSD > [[.. sneck ..]] > > Basically, if a ZFS boot drive fails, you are likely to get the following > scenario: > 1) 'What do I need to do to replace a disk in the ZFS pool?' > 2) 'Oh, that's easy.' Replaces disk. > 3) System fails to boot at some later point. > 4) 'Oh, right, you need to do this *as well* on the *boot* pool...' > > Where if a UFS boot drive fails on an otherwise ZFS system, you'll get: > 1) 'What's this drive?' > 2) 'Oh, so how do I set that up again?' > 3) Set up replacement boot drive. > > The first situation hides that it's a special case, where the second one > doesn't. "For any foolproof system, there exists a _sufficiently-determined_ fool capable of breaking it" applies. > To avoid the first scenario you need to make sure your sysadmins are > following *local* (and probably out-of-band) docs, and aware of potential > problems. And awake. ;) The scenario in the second situation presents > it's problem as a unified package, and you can rely on normal levels of > alertness to be able to handle it correctly. (The sysadmin will realize > it needs to be set up as a boot device because it's the boot device. ;) > It may be complicated, but it's *obviously* complicated.) > > I'm still not clear on whether a ZFS-only system will boot with a failed > drive in the root ZFS pool. Once booted, of course a decent ZFS setup > should be able to recover from the failed drive. But the question is if > the FreeBSD boot process will handle the redundancy or not. At this > point I'm actually guessing it will, which of course only exasperates the > above surprise problem: 'The easy ZFS disk replacement procedure *did* > work in the past, why did it cause a problem now?' (And conceivably it > could cause *major* data problems at that point, as ZFS will *grow* a > pool quite easily, but *shrinking* one is a problem.) A non-ZFS boot drive results in immediate, _guaranteed_, down-time for replacement if/when it fails. A ZFS boot drive lets you replace the drive and *schedule* the down-time (for a 'test' re-boot, to make *sure* everything works) at a convenient time. Failure to schedule the required down time is a management failure, not a methodology issue. One has located the requisite "sufficiently- determined" fool, and the results thereof are to be expected.