On 2/2/06, Ian P. Christian <[EMAIL PROTECTED]> wrote: > I would like to see an end to the 'my software RAID could have your hardware > RAID' and 'my hardware RAID could eat software RAID for breakfast' argument - > and I fear the only way to do this is with figures, not stories.
I use soft raid since about 4 years on many systems and recommend it to anyone. I use it in two scenarios: 1. on production systems, raid1 is used. It gives a big flexibility because: * I can use it on _partition_ level, not the drive level * I can easily swap drives (small differences in size does not matter, which is good because I can use drives from different vendors to minimize double failure risk) * I receive a high security from disk failure * there is no (0%) impact on performance if done correctly * I can easily swap motherboards, servers - whatever - there is no fricking problem with vendor-lockin. There is more, I can easily move one drive to other system to copy it (see below) * underlying partition in Linux raid1 are normal plain fs, which can be mounted read-only _anywhere_ * I can use it as a migration path (also with complex system reinstalls) using above tricks and having this (second raid1 drive) as a backup during operation. * I can do dangerous operation (reiserfsck --rebuild-tree) in safe way (disable one disk/partition from raid, then run operation only on one connected, if it works, add second and automatic rebuild will sync it) * I can do all of it in remote way without need of bios-type configuration 2. on systems which require high performance. Real world example: a. two WD 320GB disks (JB series, IMO one of the must buy: quiet, cool, extremely fast, 3 years warranty) b. two 100GB partitions (on each of disk) configured as a one big raid0 (200GB) partition c. two 200GB partitions (on each disk) configured as one big raid1 (200GB) partition d. remaining 40gb is out of the scope this mail e. every day, partition b. is copied to partition c, to provide backup (raid0 is twice more prone to disk failure, because even if one fails, whole raidset fails) f. everything is being kept on partition b. due to performance, only big media files and backups are on partition c. g. and now the numbers: constant sustained transfer from partition b on such server is: 120MB/s (mega bytes). CD ISO image is loaded into memory under 6 seconds. Please pay attention that such configuration gives a very good performance (outperforms most raid5 solutions including hardware ones, even based on SCSI 15000rpm u320 disks), and gives me reliability (two disk drives with raid1) and up to 1 day in data removal (raid1 does not protect from user data removal). Such solutions are cheap, effective, easy to maintain, fast and safe. That being said there are exceptions to such usage are: * more than 1TB needed * an ultra performance needed regardless cost: in such situation usage of high priced raid solutions (1+0) is preferred (but we're talking here about a small fortune I'mean EMC etc, not the 3ware SMB solutions. * other ;) Taking above exceptions I consider any standard raid controller (including SCSI ones in typical dell/hp/ibm servers) to be a worse solution than what I described. That is based on data from real ibm servers (2005 models ) with raid5 and SCSI 10k drives (70MB/s) i checked last summer. I consider addon cards for ide/sata (3ware, Sil, etc) a totally wrong solution (vendor-locking, lower performance, single point of failure, drivers problems, more maintenance needed, config in bios often needed). -- radoslaw. -- [email protected] mailing list
