Thanks Bob McGowan for your very informative reply. I gather that 1. Software raid is OK if problem is I-O bound, i.e., CPU would normally be idle waiting for I-O. 2. If we have multiple subsystems, we increase the the I-O bandwidth, and now the CPU may not be keep up with the I-O. In general, increasing I-O turns I-O bound problem into CPU bound program. 3. Software raid 5 may be OK for workload with lots of reads, but run into trouble if workload does lots of writes. 4. Software raid 5 is more efficient for large files.
Is the above more or less correct. King On Mon, 1 Jun 1998, Bob McGowan wrote: > > > > > > On Thu, 28 May 1998, Leandro Guimaraens Faria Corcete Dutra wrote: > > > <<<snipped>>> > > > The article from www.osnews.com did say that software raid takes > > up CPU cycles, but it did not say how much. It would seem that if > > the CPU must check for errors on each byte from disk and performance > > would take a big hit. Perhaps the kernel checks for errors only > > if it knows that a disk died, and normally there would not > > be a hit. Does anyone know about CPU hit of software raid. > > Why would anyone buy expensive raid hardware if software > > does the same without too much penalty? > > > > King Lee > > First, the CPU not only checks for errors on reading, it must also > calculate the parity on writes. In RAID5, spanning 4 disks, for > example, > 1/4 of the storage is used to hold parity info. Data is written in > "stripes" of some size, one stripe per disk, in a "round robin" > sequence. > One stripe will be parity. In the above 4 disk example, if a stripe > were > 16K in size, there would be 48K of data and 16K of parity. In RAID5, > the > parity stipe will "rotate" between disks, so no single disk is loaded > with > all the parity (this improves performance over RAID4(I believe) where > all > parity is on one disk). If a disk write is less than 48K, the system > must > read 48K from the disks, make the needed changes, recalculate parity and > write the resulting 64K back to the disks. If the size is 48K, this > read > of data can be dispensed with. The system must then only calcualte the > parity and then write the 64K. > > This means CPU cycles are needed for SW RAID. I do not know the impact > in terms of actual numbers, but I can say the main issue is scalability. > In SW RAID, the more RAID subsystems created, the greater the impact on > CPU performance. In HW RAID, there is no additional impact. So even if > SW RAID for a single RAID5 subsystem matched HW RAID for the same > config, > there will certainly come a breakeven point, where additional capacity > causes CPU performance degradation in the SW RAID setup. > > --- > Bob McGowan > i'm: bob dot mcgowan at artecon dot com > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]