On April 26, Bruce Guenter wrote:
> > There is an ugly hack
> > we put in to kee inode numbers < 2**32. This changes inode and
> > data placement (inodes are kept in the lower AGs, user data is
> > spread around in the upper AGs) and brings on the full-filesystem
> > case earlier. I think thats what you hit.
> Is there any way to avoid this situation?
On Irix: mount -o inode64
On Linux: rewrite linux to use 64 bit inode numbers :-)
With your filesystem, you should not be hitting the 32 bit inode
problem. It kicks in a bit above a terabyte.
I recently did some test runs similar to yours and found that a
2048-byte filesystem and directory block size was fastest. I believe
that was largely bounded by log writes. This was on some obsolete
hardware: 180mhz SGI O200 + SGI TP9100 4+1 RAID (internal log) so your
mileage will likely vary.