Steve Lord wrote:
> Very interesting, I will take a look at this some more. One initial
> comment is that optimizing for bonnie is not necessarily the correct
Agreed.
Bonnie was just convenient to illustrate the problem that I observed.
I saw this the first time after I removed a kernel source tree.
It felt a lot slower after that.
It was only then that I started paying attention to the bonnie output.
>
> thing to do - not many real world loads create thousands of files and
> then immediately delete them. Plus, once you are on a raid device,
> logical and physical closeness on the volume no longer mean very much.
>
This is another thing that is bothering me.
If you create a filesystem with only one AG all the benchmarks, tars, cps and
whatever you can dream up is a lot faster.
I concluded that the seeks accross to other allocation groups was killing
performance.
XFS with 1 AG performs similar to jfs and reiserfs on random read/write.
(Actually out performs them)
XFS with the same amount of AG's as ext2 and ext3 performs similar to ext2/ext3
on random read/write.
(Again outperforming them)
If you always use XFS with 1 AG (This would be usefull for a desktop -
AGs keeps the fragmentation down. It's not that important on a
desktop), there's a few problems:
1) You can't create filesystems bigger than 4G (4G should be enough 4 desktop)
2) You can't xfs_repair it. There is only one superblock and xfs_repair
won't work if it can't find a backup superblock.
Another drawback on having many AGs is that the
superblocks in al the AGs needs to be updated ?
This makes the disk head seek all over the platter.
I found that in real life more AGs tend to be slower, but more
fragmentation resistant and thus be faster as time goes by.
RAID devices don't seem to make much of a difference to these
observations.
>
> Having said that we need to think some more about the underlying
> allocation policy of inodes vs file data here.
>
Implimenting the core.format =local for regular files would be a nice start ;-)
This would REALLY make XFS fly for very small files.
Are there any plans to do this ?
>
> I will run a broader set of tests on this and see what the impact is.
>
> Steve
>
> p.s. congrats on getting further into XFS than most people have!
>
|