Brian Pomerantz <[EMAIL PROTECTED]> writes:
[snip]
>
> Unfortunately, the smallest stripe size I could get on the Mylex card
> is 8KB. When I tried that size, I was getting half the write
> throughput compared to a 64KB stripe size. Also, to really have
> optimal performance I need to use at least an 8KB block size (to match
> the Alpha page size).
Why does matching the the alpha page size give you better performance?
> After looking at many of the current hard
> drives, I noticed that the physical block size is variable depending
> on where you are on the platter. Almost all of the drives I looked up
> had a maximum transfer size of 64KB for a single transaction. I'm
> wondering if making the stripe size equal this transfer size * data
> drives would actually be the optimal configuration.
More likely setting filesystem read-ahead to
transfer-size * data drives would give you the performance you arre
looking for.
>
> I think the consensus here at LLNL is that for the scale that we are
> working with, a larger block size is better.
You are dealing with very large files?
> We have also found that
> if you can match the stripe size to the block size in a RAID 5, your
> write performance will be at least twice as good compared to not
> matching these up. On the ASCI Blue system, we saw a factor of 10
> performance increase on the RAID 5 systems when we matched up the
> block size to the stripe size. The reason behind this is you don't
> have to worry about the RAID controller doing a read-modify-write of a
> stripe because your block is the same size as the stripe.
I seem to be seeing a strong bias to bigger is better in the way
your are looking at things. And certainly it works that way when
you are looking at benchmarks, and the performance numbers.
However bigger is better generally breaks down when you look at the
sizes of files you need to store. Most files tend to be small causing
large block sizes to be very inefficient in terms of space.
The distribution from my pc can be seen below. Where it is clear
that with a 8K block size 76% of the blocks would be less than
half full.
Also matching strip size to block size sounds reasonable, but don't
forget that for a small file on a large block the read/modify/write
cycle must happen. Either internal to the controller or externally
in the operating system caches. So generally keeping the block size
small to avoid read/modify/write is a win.
To optimize space/performance a ext2 typically does reads/writes of
many small contiguous blocks all at one time. Which on a typical disk
yields performance as good as large block sizes without the extra size
penalty.
Eric
0 - 511 15.76% 47773
512 - 1023 16.70% 50622
1024 - 2047 24.45% 74109
2048 - 4095 19.26% 58379
4096 - 8191 10.35% 31364
8192 - 16383 6.66% 20179
16384 - 32767 3.74% 11347
32768 - 65535 1.73% 5255
65536 - 131071 0.73% 2212
131072 - 262143 0.33% 986
262144 - 524287 0.14% 437
524288 - 1048575 0.07% 217
1048576 - 2097151 0.03% 88
2097152 - 4194303 0.02% 46
4194304 - 8388607 0.01% 22
8388608 - 16777215 0.00% 8
16777216 - 33554431 0.00% 2
33554432 - 67108863 0.00% 1
---------------
303047
