From owner-freebsd-hackers Wed Jul 15 13:44:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13586 for freebsd-hackers-outgoing; Wed, 15 Jul 1998 13:44:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA13577 for ; Wed, 15 Jul 1998 13:44:47 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA11744 (5.67b/IDA-1.5); Wed, 15 Jul 1998 22:12:49 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id WAA03283; Wed, 15 Jul 1998 22:03:32 +0200 (CEST) From: Wilko Bulte Message-Id: <199807152003.WAA03283@yedi.iaf.nl> Subject: Re: Software RAID-5 performance In-Reply-To: <19980715094757.P15083@freebie.lemis.com> from Greg Lehey at "Jul 15, 98 09:47:57 am" To: grog@lemis.com (Greg Lehey) Date: Wed, 15 Jul 1998 22:03:32 +0200 (CEST) Cc: tlambert@primenet.com, gibbs@plutotech.com, andre@pipeline.ch, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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