Testing Hardware Raids

Find below what I found while testing an Adaptec's 2400a and a 3ware 6410 under Linux 2.4.x . I'm happy to share experience, your mileage may vary.

Setting up a fail-safe webserver, we checked some IDE Raid controllers:
Dump/passive controllers (no on-board extra CPU: Promise Fasttrak, AMI Megaraid 100) and active ones (on-board extra CPU: Adaptec 2400a, 3ware 6410 ). The passive ones were skipped, as it would take too long to restore an array from BIOS once the system is powered down for disk replacement. AMI does not ship the source for their driver, so they're right out. Both active ones appear as SCSI disks under Linux and are directly supported by 2.4.x kernels.
No hotswap hardware was tested so far.

Tests with Adaptec's 2400a ATA-raid controller on Linux 2.4.14

Raid BIOS

Kernel

hardware

dual P-II 400 on ASUS P2B-D board, 384MB ECC 100, (/proc/pci)

software

vanilla 2.4.14 SMP kernel compiled from scratch (.config), Adaptec: firmware 370L , SM 3.14

SCSI subsystem driver Revision: 1.00
Loading Adaptec I2O RAID: Version 2.4 Build 5
Detecting Adaptec I2O RAID controllers...
Adaptec I2O RAID controller 0 at d8825000 size=100000 irq=5
dpti: If you have a lot of devices this could take a few minutes.
dpti0: Reading the hardware resource table.
TID 008 Vendor: HIGHPOINT Device: IDEhpt370 Rev: 00000001
TID 009 Vendor: HIGHPOINT Device: IDEhpt370 Rev: 00000001
TID 010 Vendor: HIGHPOINT Device: IDEhpt370 Rev: 00000001
TID 011 Vendor: HIGHPOINT Device: IDEhpt370 Rev: 00000001
TID 519 Vendor: ADAPTEC Device: PAB01 Rev: 370L
scsi0 : Vendor: Adaptec Model: 2400A FW:370L
Vendor: ADAPTEC Model: PAB01 Rev: 370L
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 78165248 512-byte hdwr sectors (40021 MB)
Partition check:
sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
i2o_scsi.c: Version 0.0.1
chain_pool: 0 bytes @ c1670ca0
(512 byte buffers X 4 can_queue X 0 i2o controllers)


Notes:

1. a standard IDE disk appears as a standard SCSI disk and is thereby accessible
2. the kernel, lilo, mount etc. work as usual and don't get disturbed by the underlying RAID nature

User space

Installation went smoothly, even in a non-SUSE, non-Redhat system (Slackware 8.0, using rpm2cpio for files and rpm -scripts -q -p dptapps-3.14-2.i386.rpm | less for scripts): raidtool command line, plus GUI (dptmgr): (see Adaptec's side for info)

cmdline interface: raidtool -L all output

converting back to std IDE

Performance

1. Reading from /dev/sda2: dis_thru_put 1m 1m < /dev/sda2 > /dev/null 2> /var/disc_timings/raw.3
   

2. Reading from filesystem: dis_thru_put 1m 1m < /www/bkup/merkur.011001 > /dev/null 2> /var/disc_timings/filesys_read.4
   

3. Writing to filesystem: dis_thru_put 1m 1m -o < /boot/test > /www/bla 2> /var/disc_timings/filewrite.3
   

4. Interference between read (read) and write (green): (Writes go to different partion than reads)
   

5. Interference between raw read and a low level 'verify' (running on the on-board CPU), with background priority set at 50%
   
6. Interference between raw read and drive failing (removed power from drive), with hotspare
   
   downtime about 15sec, rebuild started with hotspare automatically
   rebuild took 45min for the 38166MB disks (14 MB/sec)

1. The 11MB/s sustained raw read speed is below disk specs.
2. Write performance (approx 15MB/s) is slightly higher than read (approx 11MB/sec), probably due to the cache onboard the 2400a
3. While writing to disc, reading comes to a standstill (why ?)
4. during a low level 'verify' of the raid-1 the read speed drops to approx. 80% (with 50% background priority), which is ok.
5. failing a drive results in a 15s break, rebuilding is 45min for 40GB (also limited by sustained data rate of disks).
6. a drive can be removed from a raid-1 array and be accessed by standard IDE, which seems a good idea