Date: Wed, 15 Jul 1998 22:03:32 +0200 (CEST) From: Wilko Bulte <wilko@yedi.iaf.nl> To: grog@lemis.com (Greg Lehey) Cc: tlambert@primenet.com, gibbs@plutotech.com, andre@pipeline.ch, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG Subject: Re: Software RAID-5 performance Message-ID: <199807152003.WAA03283@yedi.iaf.nl> In-Reply-To: <19980715094757.P15083@freebie.lemis.com> from Greg Lehey at "Jul 15, 98 09:47:57 am"
next in thread | previous in thread | raw e-mail | index | archive | help
As Greg Lehey wrote... > On Tuesday, 14 July 1998 at 20:05:16 +0200, Wilko Bulte wrote: > > As Greg Lehey wrote... > >> (trimming -fs) > > > >>> Software RAID is a data integrity issue, not a performance one, > >>> and I think making the performance argument for whatever reason > >>> (protection domain crossing, interleaved I/O, SMP scalability, > >>> etc.) is a strawman at best. > >> > >> I'm not sure that I understand what you're saying here. Obviously > >> offloading the checksum calculation (or anything else, for that > >> matter) to an external box will offload the CPU. And I can't see any > >> particular difference in data integrity between the two approaches. > > > > Software raid without stable (battery backed) storage is flawed: > > > > assume a write that had 2 disks actually write the data onto the platter > > and (e.g.) the parity data did not make it out on it's platter because your > > system crashed. Or the power went bang. Or... > > > > You now have an inconsistent raid5 set. > Correct. Similar things happen if a disk loses power while writing, > but the window is larger for RAID-5, and it's much more difficult to > detect. There are a number of "solutions", of course: > 1. Intent logging. Save some copy of the data elsewhere first. > Slow. > > 2. Battery backup. Doesn't guard against panics and non-disk > hardware failure. That is why standalone RAID boxes these days use dual RAID controllers and mirrored write back caches. Obviously this is expensive. Nothing really guards against panics. > 3. As long as the disks didn't physically fail, rebuild the RAID-5 > set after rebooting. I don't think this solves it, as you don't know which block is up to date and which block is not. Or do I miss your point? W/ _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW: http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807152003.WAA03283>