> David Lang Wrote:
>
> with only four drives the space difference between raid 1+0 and raid 5
> isn't that much, but when you do a write you must write to two drives (the
> drive holding the data you are changing, and the drive that holds the
> parity data for that stripe, possibly needing to read the old parity data
> first, resulting in stalling for seek/read/calculate/seek/write since
> the drive moves on after the read), when you read you must read _all_
> drives in the set to check the data integrity.
Thanks for the explanation David. It's good to know not only what but also
why. Still I wonder why reads do hit all drives. Shouldn't only 2 disks be
read: the one with the data and the parity disk?
>
> for seek heavy workloads (which almost every database application is) the
> extra seeks involved can be murder on your performance. if your workload
> is large sequential reads/writes, and you can let the OS buffer things for
> you, the performance of raid 5 is much better.
Well, actually most of my application involves large sequential
reads/writes. The memory available for buffering (4GB) isn't bad either, at
least for my scenario. On the other hand I have got such strong posts
against RAID 5 that I doubt to even consider it.
>
> Linux software raid can do more then two disks in a mirror, so you may be
> able to get the added protection with raid 1 sets (again, probably not
> relavent to four drives), although there were bugs in this within the last
> six months or so, so you need to be sure your kernel is new enough to have
> the fix.
>
Well, here rises another doubt. Should I go for a single RAID 1+0 storing OS
+ Data + WAL files or will I be better off with two RAID 1 separating data
from OS + Wal files?
> now, if you can afford solid-state drives which don't have noticable seek
> times, things are completely different ;-)
Ha, sadly budget is very tight. :)
Regards,
Fernando.