With MeeGo using Btrfs by default, Canonical making plans for Btrfs in as soon as Ubuntu 10.10, and Novell now pushing Btrfs in openSUSE, among other milestones for this advanced Linux file-system, we decided to see where the Btrfs performance is now at with the Linux 2.6.35 kernel that's currently in development. We compare the Btrfs performance to EXT4 and see how some of the different mount options are affecting the file-system's performance in different benchmarks.
Interesting results. Indeed I also suspect some performance impact on btrfs compress mode at least.
Also, I would be curious about the outcome with at least two additional kernel versions: stable vanilla (2.6.34) and development (2.6.35-rc2 or better current git head).
I like the quick comprehensive overview of the article. A few things which are interesting would be: CPU usage, Disk utilisation (iostat -x) to give some reference as to where the bottlenecks are and if big improvements are to be expected.
And perhaps most interesting to 'nocow' without the 'compress' because I suspect that compress has an averse effect when not using COW semantics (because the newly written data after compression may be larger or smaller than the old data leading requiring possibly complex workarounds).
But otherwise a nice quick "where are we now" update.
(And the Flexible IO Tester conclusion doesn't match the graph's description, but others already reported that)
So it's probably a good idea to stay away from BTRFS for web/email/database servers. Everything else seems fine.
Well you probably want to use btrfs for the main system only the performance sensitive data partitions are probably better served using something like ext4, at least for the time being. But for many servers performance is not that critical and they too are possibly interested in advanced btrfs features like compression, data checksumming, snapshots and per-file raid like logic (at least for the filesystem metadata as that makes most of the FS more fault tolerant than ext4 could).