From owner-freebsd-fs@FreeBSD.ORG Fri Jan 1 23:05:35 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666C91065670 for ; Fri, 1 Jan 2010 23:05:35 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1C18FC19 for ; Fri, 1 Jan 2010 23:05:34 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o01N5PjY019933; Fri, 1 Jan 2010 17:05:26 -0600 (CST) Date: Fri, 1 Jan 2010 17:05:25 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: "ticso@cicely.de" In-Reply-To: <20100101223907.GX43739@cicely7.cicely.de> Message-ID: References: <55389.88569.qm@web112405.mail.gq1.yahoo.com> <20100101204752.GW43739@cicely7.cicely.de> <20100101223907.GX43739@cicely7.cicely.de> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Fri, 01 Jan 2010 17:05:26 -0600 (CST) Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS RaidZ2 with 24 drives? 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: Fri, 01 Jan 2010 23:05:35 -0000 On Fri, 1 Jan 2010, Bernd Walter wrote: > > There are many possible reasons why this won't happen. > One of them is a simple write failure, which can't be reported back > to the filesystem, because not even a cache flush fails. For most RAID systems (and for ZFS) it is best if write failures are tossed because there should be a redundant copy somewhere else. Write failures usually indicate a completely failed disk since modern disks include their own bad-block management. The most important thing for ZFS is that transaction group writes are written in order, as demarcated by transaction group cache sync requests. Otherwise you get a scrambled pool which may require an expert human to untangle. > The main problem I see is that such controllers won't tell about > their strategy, so you are left in the dark. That is unfortunate. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/