Date: Wed, 15 Jul 1998 09:47:57 +0930 From: Greg Lehey <grog@lemis.com> To: Wilko Bulte <wilko@yedi.iaf.nl> 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: <19980715094757.P15083@freebie.lemis.com> In-Reply-To: <199807141805.UAA03774@yedi.iaf.nl>; from Wilko Bulte on Tue, Jul 14, 1998 at 08:05:16PM %2B0200 References: <19980714122952.L754@freebie.lemis.com> <199807141805.UAA03774@yedi.iaf.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980715094757.P15083>