From owner-freebsd-hackers Tue Jul 14 17:19:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08658 for freebsd-hackers-outgoing; Tue, 14 Jul 1998 17:19:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08653 for ; Tue, 14 Jul 1998 17:19:30 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id JAA16563; Wed, 15 Jul 1998 09:47:57 +0930 (CST) Message-ID: <19980715094757.P15083@freebie.lemis.com> Date: Wed, 15 Jul 1998 09:47:57 +0930 From: Greg Lehey To: Wilko Bulte Cc: tlambert@primenet.com, gibbs@plutotech.com, andre@pipeline.ch, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG Subject: Re: Software RAID-5 performance References: <19980714122952.L754@freebie.lemis.com> <199807141805.UAA03774@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807141805.UAA03774@yedi.iaf.nl>; from Wilko Bulte on Tue, Jul 14, 1998 at 08:05:16PM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 3. As long as the disks didn't physically fail, rebuild the RAID-5 set after rebooting. None of these is nice. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message