[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55412EE2.30103@gmail.com>
Date: Wed, 29 Apr 2015 15:20:02 -0400
From: Austin S Hemmelgarn <ahferroin7@...il.com>
To: Mike Galbraith <umgwanakikbuti@...il.com>,
Daniel Phillips <daniel@...nq.net>
CC: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
tux3@...3.org, Theodore Ts'o <tytso@....edu>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: xfs: does mkfs.xfs require fancy switches to get decent performance?
(was Tux3 Report: How fast can we fsync?)
On 2015-04-29 15:05, Mike Galbraith wrote:
> Here's something that _might_ interest xfs folks.
>
> cd git (source repository of git itself)
> make clean
> echo 3 > /proc/sys/vm/drop_caches
> time make -j8 test
>
> ext4 2m20.721s
> xfs 6m41.887s <-- ick
> btrfs 1m32.038s
> tux3 1m30.262s
>
> Testing by Aunt Tilly: mkfs, no fancy switches, mount the thing, test.
>
> Are defaults for mkfs.xfs such that nobody sane uses them, or does xfs
> really hate whatever git selftests are doing this much?
>
> -Mike
>
I've been using the defaults for it and have been perfectly happy,
although I do use a few non-default mount options (like noatime and
noquota). It may just be a factor of what exactly the tests are doing.
Based on my experience, xfs _is_ better performance wise with a few
large files instead of a lot of small ones when used with the default
mkfs options. Of course, my uses for it are more focused on stability
and reliability than performance (my primary use for XFS is /boot, and I
use BTRFS for pretty much everything else).
Download attachment "smime.p7s" of type "application/pkcs7-signature" (2967 bytes)
Powered by blists - more mailing lists