John Ronan ([EMAIL PROTECTED]) wrote on 22 April 1999 16:03:
>/dev/md2 is raid5 across 4 WDC AC313000R's (I can only work with
>what I have in the office) In the raidtab I gave it a chunk size of
>128 and I used the following mke2fs command.
>mke2fs -b 4096 0R stride=32 -m0 /dev/md2
This does look right, but I have doubts about the chunck size. Linas
discusses this issue in his old raid-howto. Basically, if you put a
small chunck size you divide most files across the disks, which means
bandwidth increases for individual files. However, you also lose
because you cannot parallelize (spelling?) the accesses. If you use a
large chunck size most files will be in a single disk, so the system
will do several accesses simultaneously. Therefore the best compromize
will depend on the workload and statistical distribution of file
sizes. There's also the question that with a small chunck size all
disks will have to work on most files, which will increase head
movement and seek time. Remember that ext2fs tends to coalesce the
blocks for a given file, but tends to spread files all over the
partition. However, you also have to take tagged queueing into account
for good scsi disks, which may produce optimizations at the
driver/disk level. You see the problem is not easy.
I'd like to have a way to measure the performance, but I don't know
how. Doug Ledford recommends using bonnie on a just-created array to
check performance with various chunck sizes. What bothers me most is
that it seems that the best settings depend on your particular files
and usage...
Another point, I'd like to build a distribution of file sizes to help
choosing the stripe size. I tried to use du for this, but du also
prints totals for directories, which is not what we want in this case.
How can you measure the file sizes of all files (including special
ones) in a filesystem? ls isn't apropriate because of files with holes.
