Re: tuning, many small files, small blocksize

[David Chinner <dgc@sgi.com>]

On Mon, Feb 18, 2008 at 03:12:44PM -0800, Linda Walsh wrote:
> 
> Might also play with the inode size.  I *usually* go with 1K-inode+4k block,
> but with a 2k block, I'm slightly torn between 512-byte inodes and 1K
> inodes, but I can't think of a _great_ reason to ever go with the default
> 256-byte inode size, since that size seems like it will always cause
> the inode to be shared with another, possibly unrelated file.

That makes no sense. Inodes are *unique* - they are not shared with
any other inode at all. Could you explain why you think that 256
byte inodes are any different to larger inodes in this respect?

> Remember, in xfs, if the last bit of left-over data in an inode will fit
> into the inode, it can save a block-allocation, though I don't know
> how this will affect speed.

No, that's wrong. We never put data in inodes.

> Space-wise, a 2k block size and 1k-inode size might be good, but don't
> know how that would affect performance.

Inode size vs block size is pretty much irrelevant w.r.t performance,
except for the fact inode size can't be larger than the block size.

> I'm sure you are familiar with mount options noatime,nodiratime -- same
> concepts, but dir's are split out.

noatime implies nodiratime.

> Also, it depends on the situation, but sometimes flattening out the
> directory structure can speed up lookup time.

Like using large directory block sizes to make large directory
btrees wider and flatter and therefore use less seeks for any given
random directory lookup? ;)

> Sometime back someone did some benchmarks involving log size and it seemed
> that 32768b(4k) or ~128Meg seemed optimal if memory serves me correctly.

128MB is the maximum size currently.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group