[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: file systems

On 5/1/2011 10:40 AM, Boyd Stephen Smith Jr. wrote:
In<4DBD0D23.1080903@hardwarefreak.com>, Stan Hoeppner wrote:
Independent Linux filesystem tests performed by an IBM engineer to track
BTRFS performance during development.  XFS trounces the others in most

These results are interesting and useful, but I think "trounces" is a poor
description for what XFS does.

Not using barriers undermines data consistency guarantees, I think it is best
to ignore the 2.6.35-rc5-autokern1-ext3-*-ext3, 2.6.35-rc5-autokern1-ext4-*-
ext4-nobarrier, and 2.6.35-rc5-autokern1-xfs-*-xfx-nobarrier entries.

It would be best for you to state something like "which results are relevant to you depend on your workload and hardware environment". Generally, anyone running a server with persistent storage is interested in the nobarrier results. Those without persistent storage should be interested in the barrier results. There are exceptions to this general guideline and I mention at least one below.

Barriers are used to flush storage device cache to avoid data loss due to a system crash or power loss. Barriers are great for low end systems lacking persistent storage. However, barriers should never be used with high performance persistent storage, i.e. RAID/SAN controllers w/ battery or flash backed write cache. Using barriers with such storage arrays simply costs you between 50-90% of your random write performance, especially with shared SAN storage and many hosts, as issuing a single barrier flushes the entire BBWC in the array controller. May enterprise arrays contain 32GB or more of BBWC.

The nobarrier results are far more relevant than the barrier results, especially the 16 and 128 thread results, for those SAs with high performance persistent storage. For desktop users the single thread barrier results are probably the most relevant. For those running mdraid all of the barrier results are relevant, and nobarrier if they trust their kernel and UPS. For those running simulation apps generating hundreds of gigs or terabytes of non volatile data, either with mdraid0 or hardware RAID0, the nobarrier results will be of the most interest.

So that btrfs doesn't remain the only filesystem with 2 entries, I'll also
ignore the 2.6.35-rc5-autokern1-btrfs-*-btrfs-nocow entry, as it is non-


On the graphs, XFS is, respectively:
2nd, 4th, 2nd, 4th


2nd, 1st, 2nd, 1st


1st, 1st, 1st, 1st


1st, 4th, 1st, 4th


2nd, 1st, 2nd, 2nd


2nd, 4th, 2nd, 2nd


5th, 1st, 5th, 1st, 3rd


5th, 1st, 5th, 5th, 1st


4th, 2nd, 4th, 4th, 2nd

I wouldn't say that is a "trouncing", since it doesn't even win in many

In those test where XFS has the best 'score' it typically beats most others by a wide margin. In those tests where is does not have the best 'score' it's usually not far below the leader. As I said before, the key is 'overall' performance. If you compare the XFS results individually against each other FS, it's apparent it beats them all handily, overall.

If you could interpret a graph correctly Boyd maybe you'd see it differently. :) Just taking the last one above as an example, you listed XFS as 4th place when it's clearly in first place, by a huge margin over all but JFS. XFS 32k, JFS 30k, EXT4 20k.

The first chart in each set of results in the important one. The others can pretty much be ignored. If you study this a bit you'll see why that's the case. As these tests are server centric, retabulate and count only the nobarrier results and only from the first chart of each test.


Reply to: