From owner-freebsd-current@FreeBSD.ORG Sat Jul 12 00:57:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACE8C1065671 for ; Sat, 12 Jul 2008 00:57:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 420358FC0A for ; Sat, 12 Jul 2008 00:57:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 6612728448 for ; Sat, 12 Jul 2008 08:57:53 +0800 (CST) Received: from localhost (unknown [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id D897DEB20A7; Sat, 12 Jul 2008 08:57:52 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id bgngxz-FxLKt; Sat, 12 Jul 2008 08:57:40 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id C1AFFEB0DC7; Sat, 12 Jul 2008 08:57:39 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=ozc3sxnZCZh8jLeY0UAddg1M6JkQdFU0NhKdrVoYwltOz18fDRJTxTtzBrs3isR8R /V6mx7PRq1udWjnMjhZ3Q== Message-ID: <48780181.2080905@delphij.net> Date: Fri, 11 Jul 2008 17:57:37 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: duncan.young@pobox.com References: <4877A343.2010602@ibctech.ca> <20080711182430.GA76378@keltia.freenix.fr> <200807121043.10473.duncan.young@pobox.com> In-Reply-To: <200807121043.10473.duncan.young@pobox.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Boot from ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2008 00:57:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Duncan Young wrote: | Be carefull, I've just had a 6 disk raidz array die. Complete failure which | required restore from backup (the controler card which had access to 4 of the | disks, lost one disk, then a second (at which point the machine paniced, Upon | reboot the raidz array was useless (Metadata corrupted)). I'm also getting | reasonably frequent machine lockups (panics) in the zfs code. I'm going to | start collecting crash dumps see if anyone can help in the next week or two. That's really unfortunate. Some sort of automated disk monitoring stuff would be essential for RAID, this includes RAID-Z. Did you used the whole disk dedicatedly for the pool, or (g)labeled before adding it into the zpool? Did 'zpool import -f' help? | I guess what I'm trying to say is, that you can still lose everything on an | entire pool, so backups are still essential, an a couple of smaller pools is | probably preferable to one big pool (restore time is less). zfs is not %100 | (yet?). The lack of any type of fsck still causes me concern. It's always true that backup is always important if data is valuable :) ~ The benefit having larger pool is that the administrator would have the ability to use larger disk space in one ZFS file system (which can not come cross zpool boundary), but it is recommended that when creating the zpool, we use smaller raid-z groups, e.g. don't use 48 disks within one raid-z group, a few disks (like 3-5) within one raid-z group would be fine. Regarding to fsck, 'zpool scrub' is pretty much like a fsck plus data integration check. It would be, however, almost impossible to recover data if zpool is completely corrupt according to some Sun sources, but my experience with bad disks within raid-z did not turned me into a unrecoverable state (yet). Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkh4AYEACgkQi+vbBBjt66A0FQCfVM/kpGQYJuNiUffxtsTgAgtJ lJIAnilKkCg1Tvf5JWd6aH9XyMjUfhBX =djMu -----END PGP SIGNATURE-----