[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zfs-discuss
Subject:    Re: [zfs-discuss] raidz vs raid5 clarity needed
From:       Ross Walker <rswwalker () gmail ! com>
Date:       2009-12-30 5:38:25
Message-ID: 38EFEDE0-B8FB-4A0E-803F-F98205E369E5 () gmail ! com
[Download RAW message or body]

On Dec 29, 2009, at 5:37 PM, Brad <beneri3@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


[prev in list] [next in list] [prev in thread] [next in thread]