[ale] RAID5 chunksize?

Jeff Hubbs hbbs at attbi.com
Tue Dec 10 12:39:59 EST 2002


I was also going to recommend testing, but I wanted to add that you
might need to give some thought as to size of files, whether the usage
in question is going to be primarily read or primarily write, and
whether the reading and writing will tend to be done sequentially or
random-access and then make sure that the testing reflects the same
characteristics.

My RAID intuition (tell me if I'm wrong, someone) tells me that for
sustained sequential reads, RAID 5 just blazes because it's reading
across the drives and not having to move the heads all that much.  On
the other hand, if you are doing lots of slapdash writes, it's slow
because it has to write to all the drives in different places (and
therefore lots of unsynchronized arm movement) and calculate and write
parity to boot.

There also may be something to sticking to integer multiples or
quotients of the drives' buffer size, but I'm unsure as to how relevant
that is.  

- Jeff

On Tue, 2002-12-10 at 11:37, Danny Cox wrote:
> Robert,
> 
> On Tue, 2002-12-10 at 10:29, Robert L. Harris wrote:
> > What is the ideal Chunksize?  
> 
> 	Well, you'll have to test.  In my case, with 85GB IDE IBM DeathStar,
> um, that is DeskStar drives, in a 4 drive RAID-5, I found the larger the
> better.  I tried every block size from 4K through 2M, and each step up
> got a little faster.  However, the larger you went, difference became
> smaller.
> 
> 	I was also using XFS, and I tested using bonnie.  So, that's just one
> data point.  If you have the time, make a small partition (otherwise the
> RAID rebuild will take a LONG time) near the middle of the disk (to get
> the average speed of the disk), and write a script to:
> 
> 	1) build a RAID-5 with the next chunksize
> 	2) wait for it to complete (watch /proc/mdstat)
> 	3) make the fs of your choice
> 	4) mount it
> 	5) run some tests
> 	6) umount it
> 	7) goto 1 (are gotos legal in text ;-)?
> 	8) plot the results (use a log scale for the sizes)
> 
> -- 
> kernel, n.: A part of an operating system that preserves the
> medieval traditions of sorcery and black art.
> 
> Danny
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale


_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale






More information about the Ale mailing list