This a report about real production experiment using both Linux
software RAID and a Mylex hardware RAID controler (real production
tend to be even harder than tests, even on a lower load, since
more special situations append).
My production server has:
2 x 8GB linux software RAID 1, Buslogic BT958 controler (ultra wild SCSI 40 at MB/s).
4 x 45GB linux software RAID 5 (0 spare), Buslogic BT958 controler (ultra wild SCSI at
20 MB/s).
6 x 50GB hardware RAID 5 (1 spare), Mylex AcceleRAID 250 (ultra wild LVD SCSI at 80
MB/s, also called ultra2 SCSI).
All cables are short, high quality, and the all server is connected to an UPS.
There is also an air cooler to prevent excessive heat.
Nb: the 4 disks ultra wild SCSI chain is running only at 20 MB/s since non
LVD ultra SCSI is unriable at 40 MB/s when there are more than 3 disks or
cable is more than 1.5 meter. Also I noticed that the Buslogic controler
is unreliable to recover from SCSI bus errors (it will sadely infinit loop
on SCSI reset) as opposed to disk errors, so it's really important to set a
conservative SCSI bus speed.
The box run like a charm several monthes long (on such a load, the previous
OS/2 server had was crashing roughly once a week), but suddenly the Mylex
contoler put all disks offline (dead) at once (while I was on holliday:
not only humans can be vicious). I just had to force them all back online,
check consistency, and it restarted.
A few weeks later, it put all disks offline again at once. This time, it
refused to get everything back nicely (since consistency check failed,
and it was putting everything back offline after only a few minutes).
So, I decided to remove the Mylex controler, and put a Tekram DC390U2W.
This model is the one I selected from a tiny study I did several monthes
ago on this mailing list through asking people what LVD SCSI controler
they where using and how happy they where. (Tekram was first, and Adaptec
second)
The problem was how to read using Linux software RAID 5, the datas
written by Mylex controler. I wrote a few test programs, and found that
the Mylex AcceleRaid controler is using what Linux software RAID calls
right-asymmetric parity algorithm (you will find the part of /etc/raidtab
file I use, at the end of this mail), so I could read the data using
Linux software RAID (mkraid --force --dangerous-no-resync /dev/md2).
Great.
So, I first checked all the disks surfaces, reading sequencialy all
the content, one disk after the other ... and found no error !!!
Then, I checked RAID 5 parity using an extended version of Pliant RAID
conversion sofware (for handling right-asymmetric parity algorithm)
and found only two corrupted chunks.
Third, I recomputed the MD5 checksum of all the 175000 files, and
compared it to the value in the database that I keep up to date on
a second computer. I had only three corrupted files (so I will need to
insert only 3 CDs to get things fixed).
Lastly, I tryed 'e2csck -n' on the new Linux sofware RAID 5 partition
and discovered no error.
So, the final unanswered question is why did the Mylex controler failed
that ungracefully if no disk contains dead blocks ?
My experimental conclusion is that Linux software RAID is even more
reliable (the two RAID sets handled by Linux sofware had no problem since
I use the right conservative bus speed), and much more flexible (enabled
me to check disks individually, and freely select the right RAID 5
configuration to match existing datas).
Thanks to Ingo and others for this great work.
I hope that this fairly long story can help (mixed with several others)
others decide more safely what they will trust most for their real work
datas (also an infinit incremental backup, and a MD5 database are great
values in any case) and know that it's possible to switch in the middle.
raiddev /dev/md2
raid-level 5
parity-algorithm right-asymmetric
nr-raid-disks 5
nr-spare-disks 0
persistent-superblock 0
chunk-size 64
device /dev/sdh
raid-disk 0
device /dev/sdi
raid-disk 1
device /dev/sdj
raid-disk 2
device /dev/sdk
raid-disk 3
device /dev/sdl
raid-disk 4
