Date: Fri, 1 Jan 2010 12:06:56 -0800 (PST) From: =?utf-8?B?xaBpbXVuIE1pa2VjaW4=?= <numisemis@yahoo.com> To: "ticso@cicely.de" <ticso@cicely.de> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, Danny Carroll <danny@dannysplace.net> Subject: Re: ZFS RaidZ2 with 24 drives? Message-ID: <55389.88569.qm@web112405.mail.gq1.yahoo.com>
next in thread | raw e-mail | index | archive | help
=0A1. sij. 2010., u 20:51, Bernd Walter <ticso@cicely7.cicely.de> napisao:= =0A=0AOn Fri, Jan 01, 2010 at 10:56:21AM -0600, Bob Friesenhahn wrote:=0AOn= Fri, 1 Jan 2010, Danny Carroll wrote:=0A=0AYou do not have this protection= when ZFS has access to the raw devices.=0AEven worse if the devices write = cache is turned on.=0A=0AThis statement does not appear to be true. ZFS wi= ll always request =0Athat devices flush their cache. The only time there i= s no =0A"protection" is if the device ignores that flush request and the ca= che =0Ais volatile. Controller battery-backed RAM is useful since the =0Ac= ontroller can respond to the cache flush request once the data is in =0Abat= tery-backed RAM, thereby dramatically improving write latencies for =0Asmal= l writes=0A=0AWhich - if it is true for the controller - can be dangerous.= =0AA battery backed cache is volatile if the system is going down for=0Aa l= ong time.=0AOr consider the system is going down to relocate the disks to a= new=0Amachine, or just to a newer controller?=0A=0A=0AIf you are using amr= driver then FreeBSD will flush cache during shutdown. Haven't tried other = drivers myself, but I suppose they also do the same.=0AYou can have a probl= em only on unclean shutdown after which you didn't reboot (nobody does that= willingly).=0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55389.88569.qm>