[K12OSN] Need Help

[Julius Szelagiewicz]

On Tue, 10 Jul 2007, [ISO-8859-1] "Terrell Prudé Jr." wrote:

> Several good points, Les.  Responses inline.
>
> --TP
>
> Les Mikesell wrote:
> > Write access is considerably slower on RAID5 and it tends to lock your
> > heads together even for reads.  I've always liked RAID1 for the simple
> > reason that if everything is broken except one disk you can still
> > recover the data it held.  Plus if you do it in software you don't
> > have to worry about having to match the controller to read on a
> > different machine.
> However, RAID 1, by definition, is not scalable beyond two disks.  So
> you're in a very similar situation (losing one disk and still going)
> here as you are with RAID 5.  And as for RAID 5 locking the heads
> together even for reads, that may well depend on your specific RAID
> card.  We haven't seen any evidence of that with our systems at work.
> However, it might well be true in some implementations, maybe to include
> software RAID.
>
> >> That said, RAID 5 kicks RAID 1 in the delicate parts when it
> >> comes to performance.  Again, we're back to, say, six or eight spindles
> >> vs. two spindles; no contest.
> >
> > That's not necessarily true.  If you configured those 8 drives in
> > RAID1 pairs, you'd have 4 independently seeking places that could be
> > writing at once and all 8 would be independent for reads.  The trick
> > is to arrange your data across the partitions so they are likely to be
> > used simultaneously.  These days you could just combine the RAID1 sets
> > into one LVM, though.
> >
> You're no longer talking about RAID 1, though.  You're talking about
> RAID 10.
>
> > > I've run many 14-disk SCSI RAID 5 setups,
> >> and my God, they were quick!!  Yes, I'm assuming a real hardware RAID
> >> card here; I generally don't recommend software RAID, no matter which
> >> RAID level you use.
> >
> > Software RAID1 works very nicely and does not add much overhead on
> > SCSI where there is not much CPU interaction anyway.  I probably
> > wouldn't do RAID5 in software.
> >
> Largely true with SCSI; I wasn't specific enough in that second
> sentence.  Oh, how I wish all disk drive interfaces were SCSI--that
> would solve plenty of problems!  But even with SCSI, we're back to the
> scalability issue; RAID 1 cannot, by definition, scale beyond two
> spindles, so if you want larger capacity, you've either got to buy two
> *huge* drives or go with RAID 5.  I certainly agree with you about not
> doing RAID 5 in software; that calls for a hardware controller.  And if
> you do go with hardware RAID controllers, then your CPU usage becomes
> independent of whether you're using PATA, SATA, or SCSI, since the RAID
> card does all that work.
>
Gentlemen,
	a couple cents worth of experience: even the most sluggish RAID 5
seems very fast if 1. controller has a lot of memory, 2. I/O buffer cache
is large. By large, I mean really large. Example: on my production HP-UX
box I have the slowest RAID known to mankind - EasyRaid, with dual
controllers maxed out at 128MB. When the system started going really slow
I upped the buffer cache from 1GB to 2.3GB (at the cost of some swapping)
- the response time was cut by 2 orders of magnitude. This is due to 99.8%
cash hit ratio on reads and 97.6% on writes. When a disk got fried I found
about it in email - there was no noticeable slowdown, even though rebuild
took 19 hours.
julius