If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Btrfs File-System Tuning On Linux 3.7

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.

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.

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?

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

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.

Originally Posted by oleid

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.