From owner-freebsd-fs@FreeBSD.ORG Fri Jan 1 22:22:57 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 3A0C2106566B for ; Fri, 1 Jan 2010 22:22:57 +0000 (UTC) (envelope-from fbsd@dannysplace.net) Received: from mail.dannysplace.net (mail.dannysplace.net [80.69.71.124]) by mx1.freebsd.org (Postfix) with ESMTP id E28788FC14 for ; Fri, 1 Jan 2010 22:22:56 +0000 (UTC) Received: from nas.lan ([203.206.171.212] helo=[192.168.10.10]) by mail.dannysplace.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NQptV-000NXW-UZ; Sat, 02 Jan 2010 08:22:54 +1000 Message-ID: <4B3E75B4.6040505@dannysplace.net> Date: Sat, 02 Jan 2010 08:22:44 +1000 From: Danny Carroll User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Bob Friesenhahn References: <568624531.20091215163420@pyro.de> <42952D86-6B4D-49A3-8E4F-7A1A53A954C2@spry.com> <957649379.20091216005253@pyro.de> <26F8D203-A923-47D3-9935-BE4BC6DA09B7@corp.spry.com> <4B3D95AD.8050304@dannysplace.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: danny X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.69 (build at 13-Aug-2009 20:22:24) X-Date: 2010-01-02 08:22:54 X-Connected-IP: 203.206.171.212:53204 X-Message-Linecount: 41 X-Body-Linecount: 27 X-Message-Size: 1993 X-Body-Size: 1126 X-Received-Count: 1 X-Recipient-Count: 3 X-Local-Recipient-Count: 3 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-SA-Exim-Connect-IP: 203.206.171.212 X-SA-Exim-Rcpt-To: bfriesen@simple.dallas.tx.us, matt@corp.spry.com, freebsd-fs@freebsd.org X-SA-Exim-Mail-From: fbsd@dannysplace.net X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ferrari.dannysplace.net X-Spam-Level: * X-Spam-Status: No, score=1.7 required=8.0 tests=ALL_TRUSTED,AWL, FH_DATE_PAST_20XX autolearn=disabled version=3.2.5 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail.dannysplace.net) 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 Reply-To: fbsd@dannysplace.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2010 22:22:57 -0000 On 2/01/2010 2:56 AM, Bob Friesenhahn wrote: > On Fri, 1 Jan 2010, Danny Carroll wrote: >> >> You do not have this protection when ZFS has access to the raw devices. >> Even worse if the devices write cache is turned on. > > This statement does not appear to be true. ZFS will always request > that devices flush their cache. The only time there is no > "protection" is if the device ignores that flush request and the cache > is volatile. Controller battery-backed RAM is useful since the > controller can respond to the cache flush request once the data is in > battery-backed RAM, thereby dramatically improving write latencies for > small writes > Yeah I should have been more clear on that. When this happens on the controller, it can be an issue if the controller decides not to commit the data to disk (as others have pointed out). Last time I looked into this I think I read that some controllers will flush to disk, some will simply be "OK" once the write to cache has occurred. Given that the BBU is optional on most array cards anyway, I never understood why a vendor would chose *not* to flush to disk. -D