[Btrfs-devel] btrfs stability

[David Chinner]

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