IDS Forum

Re: Raid 5

Posted By: ART KAGEL, BLOOMBERG/ 731 LEXIN
Date: Wednesday, 18 May 2005, at 6:09 p.m.

In Response To: Raid 5 (Danny Wright)

It is to laugh. Tell them you want to benchmark the write speed differences
(and be sure to compare with RAW devices). Also ask then how they prevent the
partial media failure problem? Only EMC tries and that's the DG Clariion
technology that I know is not sufficient.

That EMC schema is this (and I can't imagine anyone else has come up with a
better one): Add a hidden 8 byte CRC code to every disk block (essentially
redefine a disk block to be 520 bytes but have the array drivers strip off the
CRC code and return only the 512 bytes that the OS expects. This CRC code is
supposed to be able to reconstruct larger (up to 32bits IB) corruption per block
than the drive's 1 byte CRC code.

However, the problem happens LONG before the block ever gets to the firmware
that checks the CRC code. When the media begins to fail, the drive detects it
and is able to correct it for a while using it's own CRC (or other ECC) coding.
When it detects a block that is corrupted, it corrects the data if it can and
rewrites the data to a new block reserved for remapping and logically replaces
the failed block with the good one. So whenever you ask for block 27 after that
you actually get block 12342 or something like that. It does this without
reporting ANY errors so the array's firmware never knows that the platters are
beginning to become flaky. Also since the data's been corrected before being
returned the EMC ECC coding is never triggered.

Meanwhile, one block is not all that's trashed, it's just what's been found so
far. Eventually the drive will silently replace as many blocks as it can until
it runs out of remap blocks, it will then, finally, begin reporting errors to
the OS and the array firmware. However, by that time, it's as likely as not
that the embedded CRC codes have also been trashed and are useless.

IFF the CRC coding were stored independent of the failing drive, MAYBE it would
be safer. But, THAT'S what RAID 3, 4, & 5 are trying to do. The problem is
that these codes are not checked at read time or write EVER in a RAID5 array!
They are ONLY used to reconstruct a failed or manually removed drive. By that
time the bad data on one drive has been used to calculate garbage parity on the
parity blocks on the remaining drives so the reconstructed blocks of the
replacement drive are garbage as well.

NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!!

Art
----- Original Message -----
From: Danny Wright <dwright@sherwoodfoods.com>
At: 5/18 16:50

Someone's trying to sell us on RAID 5 and I haven't reviewed Art's
objections lately.

They're saying all our concerns are no longer valid.


Agree or disagree?

Messages In This Thread

• Raid 5
  Danny Wright -- Wednesday, 18 May 2005, at 3:49 p.m.
  • RE: Raid 5
    Konikoff, Rob \(Contractor\) -- Wednesday, 18 May 2005, at 4:44 p.m.
  • RE: Raid 5
    mosserp@wellsfargo.com -- Wednesday, 18 May 2005, at 5:40 p.m.
  • Re: Raid 5
    ART KAGEL, BLOOMBERG/ 731 LEXIN -- Wednesday, 18 May 2005, at 6:09 p.m.
  • RE: Raid 5
    Colin Bull -- Thursday, 19 May 2005, at 7:15 a.m.
  • Re: Raid 5
    Obnoxio The Clown -- Thursday, 19 May 2005, at 1:29 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.