Performance of Samba across various Linux filesystems

[tridge at samba.org]

Steve,

 > Our Linux filesystem performance test lead commented  "As mentioned in the 
 > LKML thread DBench only uses about 10MB/client.

closer to 22MB

 > I forget how many clients were run when collecting these results,
 > but the entire data set fit in the 2GB memory of the Server.

The graph extends to 150 clients. 150x22 > 2G.

See http://samba.org/~tridge/xattr_results/noxattr.png
and http://samba.org/~tridge/xattr_results/xattr.png

 > Apparently current test results when the benchmark working set
 > exceeds the server side memory size the results still show the
 > expected (ext3 slow, jfs and xfs faster) on most server fs
 > benchmarks.

I'm afraid I don't believe it. I am not saying that jfs is inherently
slow, but I do think that there is a serious bug that this test shows
up.

Remember that dbench is one of only a very few benchmarks that tests
an operation mix from many clients, as opposed to just testing
streaming reads or writes. The only other one I can think of is
SpecFS, which of course is NFS specific so the patterns of access are
entirely different (the synchronous nature of NFS totally changes
things).

The only way I can possibly explain the jfs results is that there is a
serious locking bug in the jfs code in 2.6.10-rc2 that is severely
limiting scalibility.

 > Be interesting if others have more data points.   Due to the lack of good 
 > quota support on ext3, I suspect most real world big server users still 
 > would lean to XFS or JFS.

If its was 20% or even 50% then maybe that might be the case, but with
a 30x slowdown under common loads that just isn't plausible.

The jfs guys should be looking for a bug.

Cheers, Tridge