keep your stripe unit close to the maximum read size of your physical disk
(in other words, your stripes should approach a multiple of the disk's
track size, in sectors). this is the most efficient unit of I/O the
disk can do. host buffering will handle the small stuff.
if your stripe unit is small, then the disks will end up doing a bunch of
small reads. if the stripe size is large, then the "small reads" are
automatically coalesced into a large read. and if the read is aligned
with the track cache, it is more likely that the disk's own read-ahead
and caching systems will be able to work efficiently.
that's the theory, anyway. your best bet is to get a file system
benchmark you trust, and that mimics your application's disk access
patterns, and use that to measure which configuration is best.
using a large filesystem block size (like 4k) is also very good, as tomas
points out.
On Thu, 30 Sep 1999, Tomas Fasth wrote:
> David Cooley wrote:
> > If you'll have lots of small files, try a chunk size of 4K... should keep
> > waste to a minimum. On the other for the mirror FTP, 16 is probably a good
> > compromise.
>
> AFAIK, chuck size affects only performance, not waste of disk. I seem
> to recall that it controls how many 1k disk blocks is accessed on one
> disk before switching to the next. Am I right?
> On the other hand, choosing a suitable block size when creating a
> filesystem is quite important and tightly connected to the predicted
> average file size. If you make a bad choice here, waste (or inode
> starvation) is then a real issue. But that problem exist whether or
> not you're using a RAID system.
> I have seen recommendations of using chunk sizes as high as 256 on
> large RAID-5 (>50GB). I have seen no proof whether this is a good
> choice or not. For example, I have for a ~100GB RAID-5 md device
> choosen a chuck size of 256, a block size of 4k, and a stride of 64
> (as parameter to mkfs). The performance seem okey so far.
- Chuck Lever
--
corporate: <[EMAIL PROTECTED]>
personal: <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/
