On Sat, Mar 08, 2008 at 11:16:55PM +0100, Rekrutacja119 wrote: > 2.6.24 kernel, also i see other people start to notice xfs problems too: > http://www.t2-project.org/zine/1/ ( i also saw other benchmarks)
<sigh - not this again> > it is second day that only thing i do is test different fs ( i need to > choose which one to use quickly ), and when it comes to small files, reading > them , listing large number of subdirs, xfs seems to have TRAGIC > performance. i mean it can be like 100 times slower in some cases. ( you can > see performance results of the other person in a link i pasted ) > > i will try 2.6.25-rc but i doubt it will bring back xfs to normal > performance state. something is really wrong with xfs, and i just see it on > my server for some time. <bigger sigh> Yes, XFS is slower on metadata intensive operations than other filesystems for a certain set of common tests. Big deal. XFS was designed for parallelism, large arrays of disks, lots of files, large files, large directories, etc, and so when it's not all that fast when it comes to dealing with small files. It was designed *15 years ago* to slow down *less* than other filesystems as the dimensions of the system and working set increase. It was not designed for optimal performance on benchmarks centred around a kernel developer's workload. My point is that filesystems are designed for different purposes. XFS is not broken because it performs less well in a workload that it wasn't designed for - it simply demonstrates tradeoffs in implementation used to acheive the necessary requirements. Hence if a given filesystem doesn't suit your workload then you should either switch to a different filesystem or help try to address the problems you are experiencing in the filesystem you are using.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
