[wellylug] preliminary SATA Linux software RAID0/RAID1 comparison

[Brent Wood]

--- Cesare D'Amico <cesare at ngi.it> wrote:

> Alle 23:24, martedì 12 ottobre 2004, Wood Brent ha scritto:
> > Dunno about RAID0 & RAID1, my guess is that as RAID1 actually does
> > twice the I/O, it will be significantly slower on writes, (where good
> > hardware RAID can gain).
> 
> I think that if you put the drives on two different channels, the writes 
> can be in parallel, so you shouldn't notice such a slowdown... methinks 
> (never tried, at the moment I'm stuck with a non-hardware promise raid 
> "controller" which is actually software raid, and I can't find a piece 
> of software to check if one of the disks dies... if I knew it was 
> actually software, I'd used linux' own software raid, for which I can 
> use mdadm... damn...).

Um... Given that the RAID1 we are talking about is implemented via software,
the OS still needs to run the code to write it twice, once to each disk. No
difference there whether the drives are on the same or different channels.

With hardware RAID1, the OS writes once to the controller, which then writes to
both disks. So with software RAID1, the cpu overhead is likely to be greater
than with a hardware implementation. Probably somewhere less than double.

With RAID0, writes are to two disks, but 'tis only actually written once. So
some cpu load in sorting out which data goes to what disk, but only the one
write. So half the actual data volume to shift.

I agree that the hardware will generally respond faster to the OS instructions
if the drives are on separate channels, that's why I'm using SATA drives.


What I'm looking at doing to get the best of all worlds, is a 20+20Gb RAID0 for
a working area, giving 40Gb of very fast read filesystem for large files. Add a
20+20 RAID1 for a secure data repository. I move files to the RAID0 when I'm
using them, & copy back if updated or just delete if unchanged. 

Postgres database is on the RAID0, with a cron database dump bzip2'd to the
RAID1 partition nightly.

It will involve a bit of hands on data/file management to get the best out of
it, but should give me performance where I need it with a better level of data
security than just striping.

If this works well, and if I/O is still a problem, I have the option (if I can
justify the $$) of moving to 2x WD 74Gb Raptor drives, which, looking at the
benchmarks, should boost I/O by at least 50%.

I just need a few days to play & see if I'm memory, cpu or I/O bound. Some jobs
are still gonna take days, just fewer of them.


As usual, any ideas/suggestions to help tweak it (within budget :-)
appreciated...


   Brent



Brent