[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    Re: file systems
From:       Stan Hoeppner <stan () hardwarefreak ! com>
Date:       2011-05-02 9:14:05
Message-ID: 4DBE75DD.80900 () hardwarefreak ! com
[Download RAW message or body]

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
>> tests:
>
> 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-
> default.
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_La
>> rge_file_creates_num_threads=1.html
>
> On the graphs, XFS is, respectively:
> 2nd, 4th, 2nd, 4th
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_La
>> rge_file_creates_num_threads=16.html
>
> 2nd, 1st, 2nd, 1st
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_La
>> rge_file_creates_num_threads=128.html
>
> 1st, 1st, 1st, 1st
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_La
>> rge_file_random_writes._num_threads=1.html
>
> 1st, 4th, 1st, 4th
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_La
>> rge_file_random_writes._num_threads=16.html
>
> 2nd, 1st, 2nd, 2nd
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_La
>> rge_file_random_writes._num_threads=128.html
>
> 2nd, 4th, 2nd, 2nd
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_Ma
>> il_server_simulation._num_threads=1.html
>
> 5th, 1st, 5th, 1st, 3rd
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_Ma
>> il_server_simulation._num_threads=16.html
>
> 5th, 1st, 5th, 5th, 1st
>
>> http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/2.6.35-rc5_Ma
>> il_server_simulation._num_threads=128.html
>
> 4th, 2nd, 4th, 4th, 2nd
>
> I wouldn't say that is a "trouncing", since it doesn't even win in many
> categories.

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.

-- 
Stan



-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/4DBE75DD.80900@hardwarefreak.com

[prev in list] [next in list] [prev in thread] [next in thread]