Index of /pub/linux/people/emoenke/ide-raid

      Name                                               Last modified       Size  Description


[DIR] Parent Directory                                   08-Sep-2005 16:45      -  
[TXT] README                                             23-Sep-2004 00:44     3k  
[DIR] bonnie++/                                          11-Sep-2004 11:54      -  
[TXT] edoc1.html                                         17-Jul-2003 23:55    11k  
[TXT] edoc2.page1.txt                                    18-Jul-2003 00:45     2k  
[TXT] edoc2.page2.txt                                    18-Jul-2003 00:46     2k  
[TXT] ftp3.html                                          17-Jul-2003 23:55    11k  
[TXT] ftp4.txt                                           18-Jul-2003 00:47     2k  
[TXT] mod+ora3.html                                      17-Jul-2003 23:55    11k  
[TXT] ora1+ora2.page1.txt                                18-Jul-2003 00:43     2k  
[TXT] ora1+ora2.page2.txt                                18-Jul-2003 00:43     2k  
[DIR] status-scripts/                                    28-Apr-2004 18:52      -  
[TXT] x4.html                                            16-Sep-2003 21:20    11k  

These are some equipment, configuration and performance data
of the IDE raids I have in use.

ftp4 is an old 8-channel device with v.24 maintenance port.

Most interesting today are the 12-channel devices:

I have 3 generations of chassis/controller hardware in use,
all of them the same line. For technical details, see
  http:://www.triplestor.de  
Look for "STOR3DISC RAID SYSTEMS", then "STOR3DISC IDE RAID",
then "STOR3DISC Slimline IDE Data sheet".

The oldest 12-channel type has a V.24 maintenance port only,
the "middle generation" type has V.24 plus ethernet, the actual
devices have V.24 plus ethernet.

"old type" are:    edoc2, ora1+ora2
"middle type" is:  mod+ora3
"actual type" are: ftp3, edoc1, x4

The actual type has increased controller performance and important
new firmware options:
 - "partitioning" of a raid set possible, making all heads available
     for each volume
 - the 2 TB size limit for a raid set has gone

I have successfully flashed this new firmware into my "middle type"
controller and one of the "old type" controllers, too.

For maintenance, currently a cron job is fetching the status data
regularly. With help of the dcon0.97.tgz package (see sunsite.unc.edu
under /pub/Linux/system/Serial) this is working with the "V.24 only"
devices, too.

The different disk types:

  IBM/Hitachi 120 GB, 7200 rpm, 2 MB cache
  IBM/Hitachi 180 GB, 7200 rpm, 8 MB cache
  Maxtor 200 GB, 7200 rpm, 8 MB cache
  Maxtor 250 GB, 5400 rpm, 2 MB cache

are showing that the IBM/Hitachi disks generally stay cooler. The
7200/5400 difference is of course a performance factor, and I guess
I can feel the better seek latency of the IBM/Hitachi disks, too.

All arrays are set up as raid-5 with one hot spare disk, with two
exceptions:

mod+ora3 has 9 disks raid-5, 2 disks raid-1, 1 disk hot spare
x4       has 12 disks raid-10 (i.e. 6 pairs raid-1, above these raid-0)

A comparision of the bonnie++ measurements: x4 versus ftp3 or edoc1
shows that raid-5 is only about 10% slower than raid-10.
This seems to be against all raid performance theory, but together
with the generally very high performance values, it simply shows that
the latest controller generation of the TripleStor Masscope IDE Raids
is no longer the bottleneck of the system.

During all bonnie++ runs, write caching was disabled for all disks and
for the controller cache.
The bonnie++ runs were without any "tuning" parameters. bonnie++ obeys
itself the buffer cache size, so the file sizes are always larger than
the current RAM amount.

Satalis and Recall (rc15-x.y in my table) are newly available IDE raids
at Triplestor/Transtec.
Satalis is about the performance class like Masscope - possibly a
little bit lower regarding performance (concurrent I/Os per second
only, not single process throughput), but has some new firmware features
like S.M.A.R.T. monitoring with warning BEFORE a disk failure (based
on defect list growing).
The Recall seems to be a likely ancient design (you have to enter
commands with parameters at the serial port for monitoring), but
throughput is about 30% better than everything else. And this ancient
design allows monitoring health via cronjob again - this feature got
missed with the Masscope+ arrays (menues and colors at the serial port -
it seems Infortrend's firmware crew is celebrating Halloween, I can only
hope for them to find back to the roots).

                       040922 Eberhard Mönkeberg, emoenke at gwdg.de