From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 08:32:06 2008 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 9C0FC10656D3 for ; Mon, 3 Nov 2008 08:32:06 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: from web36603.mail.mud.yahoo.com (web36603.mail.mud.yahoo.com [209.191.85.20]) by mx1.freebsd.org (Postfix) with SMTP id 612738FC96 for ; Mon, 3 Nov 2008 08:32:06 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: (qmail 11377 invoked by uid 60001); 3 Nov 2008 08:31:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=RKu7u259kTzreffSpNXFk9DMe8CjgkhmK+ufQQdVcJxgBdydxSXHMUP7d4hjk03gc14zcBnAB7YvZCDUpOfchdPLmuFWfR7oUc/OuR/HMDv1BtQJXN86zaRl+R0dMRZN8GAuJaibFzJiMUxC+kV/Kdb1M1Zc6myeAYoaUSP8aJ8=; X-YMail-OSG: u9EQ1nMVM1lVEAdBNvlzduWxo4Rez.X_MZ8IgjjpQZzdMHKo1_cSkpr5AJ5yjld7eME4bLiGzlvplzEcgGNTgHBb39QxcBcQE7euxfPc4eEvrkpQZCAHDU10BIXri_sRKOMcPr_mnQh1PctqCXEZrhPR3OTlM9ELGUKmLPND Received: from [213.147.110.159] by web36603.mail.mud.yahoo.com via HTTP; Mon, 03 Nov 2008 00:31:57 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Mon, 3 Nov 2008 00:31:57 -0800 (PST) From: Simun Mikecin To: Peter Schuller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <723911.11212.qm@web36603.mail.mud.yahoo.com> X-Mailman-Approved-At: Mon, 03 Nov 2008 12:24:03 +0000 Cc: freebsd-fs@freebsd.org Subject: Re: Areca vs. ZFS performance testing. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: numisemis@yahoo.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2008 08:32:06 -0000 Peter Schuller wrote: > In any case, why would the actual RAID controller cache be flushed, > unless someone expliclitly configured it such? I would expect a > regular BIO_FLUSH (that's all ZFS is going right?) to be satisfied by > the data being contained in the controller cache, under the assumption > that it is battery backed, and that the storage volume/controller has > not been explicitly configured otherwise to not rely on the battery > for persistence. I'm using amr(4) driver with Dell PERC 4e/DC controller (which is a rebranded LSI 320-2E) that has battery-backed cache and write-caching configured to be write-back. This controller is connected to a LED light that shows when there is something in the cache not yet commited to the disks. Ever since I changed from UFS2 to ZFS that light comes off very quickly. It does not stay on for longer periods of time (it did for upto 10 seconds when I used UFS2 - it is a controller BIOS setting). So doing BIO_FLUSH in this case *does* flush battery-backed cache. I can restore old functionality by setting vfs.zfs.cache_flush_disable=1 but I shouldn't use it in my case since the same system also has SATA disks with ZFS on them and turning off BIO_FLUSH for SATA disks would be dangerous. > Please correct me if I'm wrong, but if synchronous writing to your > RAID device results in actually waiting for underlying disks to commit > the data to platters, that sounds like a driver/controller > problem/policy issue rather than anything that should be fixed by > tweaking ZFS. AFAIK as I know BIO_FLUSH (which is for now implemeted only for ata(4) and amr(4) - correct me if I'm mistaken) does just that: actually flushes and waits for the cache content to be written on disk. > Or is it the case that ZFS does both a "regular" request to commit > data (which I thought was the purpose of BIO_FLUSH, even though the > "FLUSH" sounds more specific) and separately does a "flush any actual > caches no matter what" type of request that ends up bypassing > controller policy (because it is needed on stupid SATA drives or > such)? AFAIK BIO_FLUSH commits *everything* that is in the cache. It is needed for stupid SATA drives. But I'm not so happy about it been turned on for amr(4) flushing the entire 128MB battery backed cache.