RAID5 chunksize?

Ok, say I'm building a 4 disk raid5 array. Performance is going to be critical as this system is going to be very IO intensive. We had to go RAID5 though due to filesystem requirements.

According to the manufacturer the disks have:

8Meg DataBuffer
10K RPM Rotational speed
SCSI Ultra 160

(Drive is:
http://www.fel.fujitsu.com/home/product.asp?L=en&PID=248&INFO=fsp)

What is the ideal Chunksize?

Also it's going to have a lot of pretty decent sized files (100Meg or so average) so I was going to make it an ext3 with -T largefile and -M 1.

Any other thoughts on how to lay down the disks/filesystem on this bugger?

Robert

:wq!
---------------------------------------------------------------------------
Robert L. Harris | PGP Key ID: FC96D405

DISCLAIMER:
These are MY OPINIONS ALONE. I speak for no-one else.
FYI:
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Measure.

Try 4k, 32k, 128k, and see which is best.

Please post the results to the list :)

It is important that you benchmark not with tiotest or bonnie, but with the actual applications that need to use this server.

................................................................
:   [email protected]   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

That depends on your definition of ideal, unfortunately.

Yes, I got a chance to spend a LOT of time tuning RAID, and got to see what various settings actually did.

You have to decide if you want to have maximum transfer rate or minimum seeks on the drive. Some of the changes impact one at the expense of the other.

If you want to reduce seeks, make the stripe size larger than most of the i/o requests, so you access at most two drives. This will reduce your seeks, a too-small stripe can result in activity to most of the drives for most i/o operations. Lots of seeks, and bad performance if transfers are fairly small, a request can't complete until the slowest seek+transfer is complete.

If the typical write is large, defined as transfer time significantly more than seek time, you can improve transfer rate by spreading the transfer over multiple drives, as long as you don't overload your bus. This last gets important, a few controllers with multiple sets of LVD-160 or faster drives can start to stress the PCI bus, and enough DMA (or similar bus master i/o) can actually hit the memory hard enough to measure in the CPU access time. Clearly these limits are not typical, you idea of high rate might be idle on some NUMA or cluster. Since this increases the seek rate on individual drives, you can hurt more than you help with certain loads.

Finally, if you have a very high read rate and much lower write rate, you can help with RAID-1, so that data on one (busy) drive can be pulled from a mirror. You *can* have more than two mirrored copies, if your load justifies it.

Hope some of this helps you answer your own question.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.