Date: Sun, 12 Feb 2006 09:20:32 -0800 From: Bakul Shah <bakul@BitBlocks.com> To: soralx@cydem.org Cc: freebsd-hackers@freebsd.org Subject: Re: RAID5 on athlon64 machines Message-ID: <200602121720.k1CHKWFY089596@gate.bitblocks.com> In-Reply-To: Your message of "Sun, 12 Feb 2006 01:27:03 PST." <200602120127.03988.soralx@cydem.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > You compute max data rates by considering the most optimistic > > scenario, which is large sequetial writes. For *this* > > situation write rate will be higher than a single disk's. > > How can the RAID5 write rate be higher for the whole array if not > only it needs to write the data to all if its drives, but also > compute and write a parity block? You write to all the disks at the same time. While the disks are busy writing you compute parity for the next stripe. In my case disk bw is 60MB/s. Memory bw is I thin 3GB/s. There ought to be plenty of bw and cpu for xor computing. > IMO, RAID does not protect against system crashes - all it does > is provide performance increase and/or some protection against > hardware failure (which will be detected with extremely high > probability) enabling the admin to restore some data. No it can't if you don't do the parity check on reads and a previous write to the stripe was incomplete due to system crash. You will happily deliver incorrect data to the user and he only knows *something* is wrong when his system crashes or program misbehaves or some binary data doesn't quite feel right or some text is garbled or some secondary bad effect. May be you need to use the same principle in your learning? Check your understanding by applying it and trying to extend it. Don't just believe what you read, cross-check it. Question the (so called) authority! The revolution will not be televised. Oops I think I have a scrambled brain block.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200602121720.k1CHKWFY089596>