Messages in this thread | | | Date | Sun, 29 May 2005 19:01:38 -0400 | From | Wakko Warner <> | Subject | Re: RAID-5 design bug (or misfeature) |
| |
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/
| |