Date: Sat, 02 Jan 2010 08:22:44 +1000 From: Danny Carroll <fbsd@dannysplace.net> To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS RaidZ2 with 24 drives? Message-ID: <4B3E75B4.6040505@dannysplace.net> In-Reply-To: <alpine.GSO.2.01.1001011050280.1586@freddy.simplesystems.org> 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> <alpine.GSO.2.01.1001011050280.1586@freddy.simplesystems.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B3E75B4.6040505>