From owner-freebsd-fs@FreeBSD.ORG Sun May 6 20:59:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 926D8106564A for ; Sun, 6 May 2012 20:59:43 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 3554C8FC12 for ; Sun, 6 May 2012 20:59:42 +0000 (UTC) Received: (qmail 42031 invoked by uid 110); 6 May 2012 20:59:41 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 6 May 2012 20:59:41 -0000 From: "Simon" To: "Bob Friesenhahn" Date: Sun, 06 May 2012 16:59:41 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120506205943.926D8106564A@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS Kernel Panics with 32 and 64 bit versions of 8.3 and 9.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 20:59:43 -0000 I fully understand the concept behind ECC memory and why it is important to use it in a server environment, especially with a filesystem like ZFS. However, I think my entire point was missed. It appears there are simply too many documented cases where entire pool becomes inaccessible due to limited corruption. Most of the data is still intact but there is no way to recover it. And there is no way to fix the limited inconsistencies which caused the entire pool to become unimportable to begin with. Again, I'm okay with few corrupted or missing files. I'm not okay with entire pool becoming inaccessible due to limited corruption due to faulty memory or otherwise. There needs to be a way to import a corrupted zpool and at very least to be able to read the remaining intact data. -Simon On Sun, 6 May 2012 09:59:39 -0500 (CDT), Bob Friesenhahn wrote: >On Sun, 6 May 2012, Simon wrote: >> >> Are you suggesting that if a disk sector goes bad or memory corrupts few blocks >> of data, the entire zpool is gonna go bust? can the same occur with a ZRAID? >> I thought the ZFS was designed to overcome all these issues to begin with. Is >> this not the case? >ZFS is designed to work with failing disks, but not failing memory. >It is recommended to use only systems with ECC memory. >The OS itself (any OS!) is succeptible to crash/corruption due to >failing memory but without zfs's checksums, you might not be aware of >such corruptions or the crash might be more delayed. >Bob >-- >Bob Friesenhahn >bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ >GraphicsMagick Maintainer, http://www.GraphicsMagick.org/