Btrfs File-System Tuning On Linux 3.7

[phoronix]

Phoronix: Btrfs File-System Tuning On Linux 3.7

Earlier this week I posted new Reiser4 file-system benchmarks that compared the non-mainline file-system against EXT4, Btrfs, XFS, and ReiserFS. Continuing in the Linux file-system performance theme, in this article are more Btrfs benchmarks from that same system but when using the early Linux 3.7 development kernel and trying out different Btrfs mount/tuning options.

http://www.phoronix.com/vr.php?view=18022

[jwilliams]

Why does noatime produce a significant SLOWDOWN in some of the tests (IOzone, threaded-IO)? This makes no sense to me. Is it a bug in btrfs, or in the benchmark tests, or something else?

[blackout23]

Is there a similar benchmark for ext4? I'm currently using noatime and discard for mounting it.

[GreatEmerald]

Interesting benchmark there. Good to know that inode caching has a (minimal) positive effect.

And yeah, lzo compression seems to lead to lolspeeds.

[jwilliams]

And yeah, lzo compression seems to lead to lolspeeds.

That is not very meaningful, since several of the benchmark programs write unrealistic highly compressible data (streams of zeros). With real data, the compression options will have only a small effect.

[oleid]

Why does noatime produce a significant SLOWDOWN in some of the tests (IOzone, threaded-IO)? This makes no sense to me. Is it a bug in btrfs, or in the benchmark tests, or something else?

+1

And is there any reason, why lzo should not be enabled by default when using a modern processor? It probably won't be able to compress already compressed data. Yet, would it make the disc usage in this cases worse?

[unknown2]

+1

And is there any reason, why lzo should not be enabled by default when using a modern processor? It probably won't be able to compress already compressed data. Yet, would it make the disc usage in this cases worse?

i test btrfs recently (with a sandy bridge processor), it seems that compression will introduce the following side effect

1. The maximum size of extent will be limited to 256K, leading to heavier fragmentation and more metadata
2. increase latency when read, my VM is slower when compression is on

btrfs might need to decompress the whole extent before reading even one byte

3. bootloader may not support corresponding compression

[GreatEmerald]

That is not very meaningful, since several of the benchmark programs write unrealistic highly compressible data (streams of zeros). With real data, the compression options will have only a small effect.

Yea, I know. But there should still be a bit of performance boost, as well as disk space boost.

And is there any reason, why lzo should not be enabled by default when using a modern processor? It probably won't be able to compress already compressed data.

Btrfs doesn't compress already compressed data by default. It figures out what is and what isn't compressed already automatically.

[marco]

Not counting the fact that there is n update to latest lzo compression alghoritm proposed for mainline:
[GIT PULL v2] Update LZO compression
that is typically more than 2 times faster!

Marco

[crazycheese]

NEEDS RELIABILITY TESTING PLEASE!

Means fault tolerance(how good it resists damage) and fault chance(how often software-dependent/brtfs-driver faults happen)

please!!!