On Sun, Mar 05, 2000 at 02:37:26PM -0600, Eric W. Biederman wrote:
>
> Why does matching the the alpha page size give you better performance?
>
Having not looked at the code, I don't know for sure ext2 will
actually USE the full 8KB page size if the block size is not this
large. I'm going to have to assume that there is code in there to use
two 4KB blocks per page and not just use half the page. If it doesn't
do this, then you'll get a win there. Also, the smallest amount of
data you can possibly work with on the Alpha is 8KB and working in
chunks 8KB will avoid computations needed for packing data or only
using half a page.
> > 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.
>
Again, I'm looking for write performance. I really don't care about
read performance (read will always be better than write). This is for
very large HPC and scientific simulations (nuclear reactions at the
atomic level through the life-span of the reaction all the way through
decay of materials years after the reaction). These applications
generate a lot of data.
>
> 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.
>
I'm not talking about PCs, I'm talking about large clusters of
potentially several thousand nodes. Blue Pacific is the number two
machine in the world on the super-computing index (Red got upgraded
and beat us by a little bit). The world is completely different when
you have terabyte file systems with applications that can fill these
file systems in short order.
>
> 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.
>
For the most part, this can all be true of reads but I'm looking for
write performance. If the block size is the same size as your stripe
size you will NEVER see a read-modify-write sequence if your
controller behaves properly. The block is the smallest atomic unit
you can work with in most file systems. If it covers an entire stripe
on your RAID system then you will be guaranteed to write out an entire
stripe and not just a partial stripe. If you are writing a partial
stripe you would have to read a stripe, modify the stripe, calculate
parity, and write the stripe back to the disks. If your block size is
the same size as the stripe, you can theoretically avoid this entire
sequence and just calculate parity and write the block to disk at the
next available slot.
As far as I can tell, this may be all dependent on the controller's
ability to handle transactions in this way. I know we saw a HUGE
performance increase on the IBM machine when the RAID 5 system and the
file system were set up in this manner. I'd have to assume that this
is true with other controllers, certainly it is the optimal way to
design the system.
BAPper
