RE: NT and Linux
Hi, King, my comments follow your questions, below.
I hope this helps.
Bob
> King Lee asks:
>
> 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.
I would agree with this analysis. If the CPU is doing "nothing", it
might as well be calculating parity for RAID. :-)
> 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.
I would also expect this to be true, though I have no evidence to
support the idea.
> 3. Software raid 5 may be OK for workload with lots of
> reads, but run into trouble if workload does lots
> of writes.
Not necessarily. Remember, when reading the data, you still have to
read a stripe from all the disks and verify the parity, so there is
still some overhead. Also, if there are lots of writes, there may
be a higher chance of ordering the I/O requests to take advantage of
writing a full set of stripes, reducing the frequency of the
read/modify/write cycle, which will reduce I/O load.
> 4. Software raid 5 is more efficient for large files.
Generally, the answer to this is: it depends ;-) Are you talking
reads and/or writes. What combination? How random? Etc.
Also, this question (and the third, to some extent) are getting away
from the original question comparing SW and HW based RAID technnology
and are getting into the more specific issues of RAID efficiencies,
which DO NOT depend on whether the RAID is SW or HW. Generally, in
RAID5, writes will always be more expensive than a regular disk. If
you have a read/modify/parity calcualtion/write scenario, it is worse,
but even the data collection/parity calculation/write sequence takes
more time than a pure write. The efficiency of RAID5 is in its read
characteristics, for random access. Large numbers of random read
requests will distribute across multiple spindles, improving I/O due
to redcution of seek delays and an overall reduction of read requests
PER SPINDLE. There will also be less wait time for unrelated requests.
This implies that the more disks you can put in the array,
the better the performance. And this may be where SW RAID could be
better than HW RAID, since SW based arrays can span multiple
controllers.
The controllers also do not need to be the same interface type either.
You can mix IDE, SCSI, etc. HW RAID systems generally have some limits
on the number of disks you can have, based on the number of internal
buses and bus width (ie a two internal narrow SCSI channel system would
be limited to a maximum of 14 hard disks).
If you are concerned about write performance more than read performance,
you might want to consider using a mirror set of some sort (RAID1 and
RAID6 [AKA RAID10]). Since there is no parity calculation, write
performance is very close to a standard disk's. The disadvanage is
that 50% of the capacity is lost.
>
> 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 debian-user-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> >
> >
>
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: