Re: inode size benchmarking

["Christian Røsnes" <christian.rosnes@xxxxxxxxx>]

On Feb 12, 2008 1:15 PM, David Chinner <dgc@xxxxxxx> wrote:
> On Tue, Feb 12, 2008 at 12:37:36PM +0100, Christian Røsnes wrote:
> > The test server used:
> >
> >  * Debian 4 (Etch)
> >  * Kernel: Debian 2.6.18-6-amd64 #1 SMP Wed Jan 23 06:27:23 UTC 2008
> > x86_64 GNU/Linux
> >  * CPU: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
> >  * MEM: 4GB RAM
> >  * DISK: DELL MD1000 7 disks (1TB SATA) in RAID5. PERC6/E controller
> >  * The test partition is 6TB.
>                            ^^^
>
> This does, though.
>
> With 256 byte inodes, the allocator changes behaviour at filesystem
> sizes > 1TB to keep inodes at smaller than 32 bits. This change
> means that data is no longer close to the inodes, thereby seeking
> the disks more as it moves between writing data and writing inodes.
>
> With 2k inodes, that change doesn't occur until 8TB in size (as that
> is the 32bit inode number limit with 2k inodes), so the allocator is
> still keeping inode+data locality as close as possible on a fs size
> of 6TB.
>
> I suggest running the 256 byte inode numbers again with the "inode64"
> mount option (so the allocator behaves the same as for 2k inodes) and
> seeing how much difference remains....
>

Yes, with mount option inode64 the inode=256 tests now run as fast as
the inode=2048 tests.

Thanks

Christian