Testing Out The Btrfs Mount Options On Linux 3.2

[phoronix]

Phoronix: Testing Out The Btrfs Mount Options On Linux 3.2

Earlier this month I benchmarked all the major Linux file-systems of Ubuntu 12.04: ReiserFS, JFS, EXT2, EXT3, EXT4, Btrfs, and XFS. While Btrfs performed well with Ubuntu 12.04 LTS, it was not always the fastest although it does offer the most advanced feature-set. For those looking to tune a Btrfs file-system for performance, published now are some reference benchmarks showing the Linux Btrfs performance with varying mount options.

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

[drag]

FYI,

I do believe that the wiki on the kernel.org page is out of date. This has not been kept up since the kernel.org was compromised.

The up to date wiki is at:
http://btrfs.ipv5.de/index.php?title=Getting_started
http://btrfs.ipv5.de/index.php?title=Mount_options


Although it does not appear much has changed in terms of mount options.

[BenderRodriguez]

The Zlib and LZO compression tests are flawed as the FS-MARK creates empty files which obviously get near perfect compression, of course there are lots of text files on Linux system that will benefit from that but in most cases it won't benefit at all. So it is either write down WHY the LZO/ZLIB are so fast or modify FS-MARK to use some media files that won't get compressed much (or the I/O TESTER as well).

[uid313]

What about with Google's compression algorithm Snappy?

[uid313]

Imagine this with with lz4...

[r1348]

The Zlib and LZO compression tests are flawed as the FS-MARK creates empty files which obviously get near perfect compression, of course there are lots of text files on Linux system that will benefit from that but in most cases it won't benefit at all. So it is either write down WHY the LZO/ZLIB are so fast or modify FS-MARK to use some media files that won't get compressed much (or the I/O TESTER as well).

This. Compressing a bunch of 0s is a pretty easy task, fs-mark is mis-representative in this case.

[Kamikaze]

When running an Iozone write test, Zlib and LZO compression led to significantly higher results, albeit it was using compression and mostly came down to being run in the system memory at speeds not sustainable by the SATA SSD.

Michael, would you consider adding the '-e' option to the iozone test definition for pts so fsync is forced and included in calculation times?

[DanL]

Someone wake me when btrfs is faster than ext4 and actually compelling to desktop users.

[kebabbert]

Someone wake me when btrfs is faster than ext4 and actually compelling to desktop users.

I dont get it. Why this focus on speed? Why not focus on data safety? What do you prefer, fast and corrupted data or slower and correct data? If you never do any checks, it will be fast. Checksumming takes long time, but guarantees data is correct. I rather use slower and correct data, than fast and corrupted data.

[stan]

I dont get it. Why this focus on speed? Why not focus on data safety? What do you prefer, fast and corrupted data or slower and correct data? If you never do any checks, it will be fast. Checksumming takes long time, but guarantees data is correct. I rather use slower and correct data, than fast and corrupted data.

OK, so let's talk reliability. As it stands, BTRFS is much more prone to corruption and gradual degradation of speed and even available free spance than EXT4. Just look at all the reports of people saying BTRFS becomes unusable after a a few days of running. The fact is that for the vast majority of desktop users, BTRFS still has no advantage over EXT4.