Stan Hoeppner wrote:

On 3/7/2014 9:15 PM, Martin T wrote:

quoted

Stan,

ok, I see. However, are there utilities out there which help one to
analyze how applications on a server use the file-system over the time
and help to make an educated decision regarding the chunk size?

My apologies.  You're a complete novice and I'm leading you down the
textbook storage architectural design path.  Let's short circuit that as
I don't have the time.

As you're starting from zero, let me give you what works best with 99%
of workloads.  Use a chunk size of 32KB or 64KB.  Such a chunk will work
extremely well with any singular or mixed workloads, on parity and
non-parity RAID.  The only workload that should have a significantly
larger chunk than this is a purely streaming allocation workload of
large files.

If you want a more technical explanation, you can read all of my
relevant posts in the linux-raid or XFS archives, as I've explained this
hundreds of times in great detail.  Or you can wait a few months to read
the kernel documentation I'm working on, which will teach the reader the
formal storage stack design process, soup to nuts.  I wish it was
already finished, as I could simply paste the link for you, which,
coincidentally, is the exact reason I'm writing it. :)

Thank you Stan, hopefully you cover typical mixed use cases. I split my physical 
drives with partitions and built large chunk arrays on on set and small on the 
other, to cover my use cases of editing large video files and compiling kernels 
and large apps.

The ext4 extended options stride= and stripe-width= can produce improvements in 
performance, particularly when writing a large file on an array with a small 
chunk size. My limited tests showed this helped more with raid6 than raid5.

Since you're writing a document you can include that or not as it pleases you.

-- 
Bill Davidsen [off-list ref]
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot