Re: RAID-5 design bug (or misfeature)

[Wakko Warner <wakko@animx.eu.org>]

Mikulas Patocka wrote:
> RAID-5 has rather serious design bug --- when two disks become temporarily
> inaccessible (as it happened to me because of high temperature in server
> room), linux writes information about these errors to the remaining disks
> and when failed disks are on line again, RAID-5 won't ever be accessible.

I ran into this myself, however, I had 10 disks (5 per channel) and one
chennel went down.  Ok, my array was dead at that point and I had to reboot. 
What luck, the arry wasn't usable anymore.  My /usr was on that array, but
my / was not.  I did not want to go through the initrd/initramfs thing at
the time to setup my / with raid5, plus the fact you truely cannot boot from
it (thus partitioning and setting aside a slice wasn't viable to me)

> RAID-HOWTO lists some actions that can be done in this case, but none of
> them can be done if root filesystem is on RAID --- the machine just won't
> boot.

I had to reconstruct the array by hand with mdadm.  evms wouldn't touch it. 
Fortunately, I had a copy of each disk's information and the raid5's
information in files so it was quite easy to rebuild.  I did have backups
but that wasn't really what I wanted to do.  (It did take over 2 hours
before I could return to normal.  evms can't handle a raid5 that was in
reconstruction.  I think newer versions have this fixed.)

> I think Linux should stop accessing all disks in RAID-5 array if two disks
> fail and not write "this array is dead" in superblocks on remaining disks,
> efficiently destroying the whole array.

That'd be nice =)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/