On Wed, 2002-04-24 at 11:16, Paul Schutte wrote:
> 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.
I saw similar things with IOZone and dbench when using XFS and LVM. The
things about that though, is there are some bdflush fixes that I
incorporated from the -AA tree that allayed the problem, but only for a
short time. Further tweaks were necessary to actually get to a point
where the problem was minimized and some sort of balance was reached.
This test was done on a Dell 6450, 8GB RAM, and 270GB of Disks. Four
RAID0 devices.(sda 3x36, sdb 3x36, sdc 1x36,sde 1x36)
>
> >
> > 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.
>
Hrmm....that might be true as well. Though bdflush, in test cases with
2.4.17 and 2.4.18 + XFS, seems to really take a beating. Perhaps it is
caused by that in some way?
> 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)
I disagree..in the realm of 100GB disks, people may want to take 2 or 4
of them, striped, and create large archives of their music, or videos,
or perhaps a cheap, technically unimportant file server for low cost.
Using something like, MD, LVM, or EVMS to create volumes of say 100GB in
size at a time, on a 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.
>
Well..enough said on that. What's the point of redundancy in the FS, if
you can't repair your SB?
> 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.
>
I disagree slightly, only given that I can increase my speed about 2x by
usin LVM or EVMS, and XFS. (throughput numbers collected using IOZone
and Dbench)
Though repeatability of the same test over and over, without
unmounting/remounting seems to decline as time goes on.
> >
> > 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.
I would like to see what you use to test and what testing you do. I've
got a test bed I could lend with for corroberation of these tests
possibly.
> >
> > Steve
> >
> > p.s. congrats on getting further into XFS than most people have!
> >
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: austin@xxxxxxxxxxxxxxx
"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb
signature.asc
Description: This is a digitally signed message part
|