Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)

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

 



On Wednesday, April 29, 2015 12:05:26 PM PDT, 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?

I'm more interested in the fact that we eked out a win :)

Btrfs appears to optimize tiny files by storing them in its big btree,
the equivalent of our itree, and Tux3 doesn't do that yet, so we are a
bit hobbled for a make load. Eventually, that gap should widen.

The pattern I noticed where the write-anywhere designs are beating the
journal designs seems to continue here. I am sure there are exceptions,
but maybe it is a real thing.

Regards,

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux