On Dec 29, 2009, at 5:37 PM, Brad <bene...@yahoo.com> wrote:
Hi! I'm attempting to understand the pros/cons between raid5 and
raidz after running into a performance issue with Oracle on zfs (http://opensolaris.org/jive/thread.jspa?threadID=120703&tstart=0
).
I would appreciate some feedback on what I've understood so far:
WRITES
raid5 - A FS block is written on a single disk (or multiple disks
depending on size data???)
If the write doesn't span the whole stripe width then there is a read
of the parity chunk, write of the block and a write of the parity
chunk which is the write hole penalty/vulnerability, and is 3
operations (if the data spans more then 1 chunk then it is written in
parallel so you can think of it as one operation, if the data doesn't
fill any given chunk then a read of the existing data chunk is
necessary to fill in the missing data making it 4 operations). No
other operation on the array can execute while this is happening.
raidz - A FS block is written in a dynamic stripe (depending on size
of data?)across n number of vdevs (minus parity).
Yes, and since there is no write penalty it is only one operation, so
writes should be faster on raidz then raid5 (and safer). Like raid5 no
other operation to the vdev can execute while this is happening.
READS
raid5 - IO count depends on how many disks FS block written to.
(data crosses two disks 2 IOs??)
These can happen in parallel so really think of it as one operation,
but the reads only need to read from the disks the data lies on
allowing multiple read operations to execute simultaneously as long
as the data is on separate spindles. Of course no write can execute
while a read is happening.
raidz - A single read will span across n number of vdevs (minus
parity). (1single IO??)
Yes, reads are exactly like writes on the raidz vdev, no other
operation, read or write, can execute while this is happening. This is
where the problem lies, and is felt hardest with random IOs.
NEGATIVES
raid5 - Write hole penalty, where if system crashes in the middle of
a write block update before or after updating parity - data is
corrupt.
- Overhead (read previous block, read parity, update parity
and write block)
- No checksumming of data!
- Slow read sequential performance.
Sequential reads and random reads should be as fast as a raid0 of the
number of disks in the array minus one.
raidz - Bound by x number of IOPS from slowest vdev since blocks are
striped.
Bad for small random reads
POSITIVES
raid5 - Good for random reads (between raid5 and raidz!) since
blocks are not striped across sum of disks.
raidz - Good for sequential reads and writes since data is striped
across sum of vdevs.
- No write hole penalty!
That about sums it up.
Avoid raidz for random workloads, unless you have so many disks you
can create multiple raidz vdevs to accomodate the needed IOPS.
-Ross
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
