Mark,
Having a very large chunk size would reduce the performance down close to that
of a single device. Two performance factors to keep in mind: access time, and
throughput. Access time is important for the many small files and accesses
needed, and throughput is needed for large requests. Mixed in with these factors
is request overhead latency, the average seek/access time, the sustained
throughput of a single device, and the size of the devices cache buffer.
In setting the chunk size, I suppose there may be two schools of thought.
First, have the chunk size so one spindle can handle the entire request--freeing
the other spindles to work on some other areas (this increases access time), or
secondly, to have all the spindles working in parallel (this increase
throughput). And a third strategy, setting the chunk size to work well with both
large and small requests.
On a typical system, most requests (and files) are small ( < 4KB), but there
are many larger requests ( > 256KB) that load in object code. I suggest a chunk
size of around 64(KB) since it allows a greater access time when using small
requests, and also adds increase throughput for larger requests (by sharing the
requests). 128KB may work just as well, but this exceeds the size of some cache
buffers and some device drivers cannot request more than 64KB in one request.
My two cents worth.
<>< Lance.
Marc Mutz wrote:
> D. Lance Robinson wrote:
> >
> > Try bumping your chunk-size up. I usually use 64. When this number is low,
> > you cause more scsi requests to be performed than needed. If really big (
> > >=256 ) RAID 0 won't help much.
> >
> What if the chunk size matches ext2fs's group size (i.e. 8M)? This would
> give very good read/write performance with moderatly large files (i.e.
> <8M) if multiple processes do access the fs, because ext2fs usually
> tries to store a file completely within one block group. The performance
> gain would be n-fold, if n was the number of disks in the raid0 array
> and the number of processes was higher than that.
> It would give only single-speed (so to speak) for any given application,
> though.
> But then: Wouldn't linear append be essentially the same, given that
> ext2fs spreads files all across the block groups from the beginning?
>
> Would that not be the perfect setup for a web server's documents volume,
> with MinServers==n? The files are usually small and there are usually
> much more than n servers running simultaneously.
>
> Is this analysis correct or does it contain flaws?
> What be the difference between raid0 with 8M chunks and linear append?
>
> Just my thoughts wandering off...
>
> Marc
