Btrfs v0.19 Brings Some Gains, Some Losses

[phoronix]

Phoronix: Btrfs v0.19 Brings Some Gains, Some Losses

Since we began benchmarking Btrfs a few months ago we have found it to not deliver any spectacular file-system performance results on Linux. This next-generation Linux file-system that has often been compared to Sun's ZFS has not really performed that well, granted it's still very much under development. Btrfs is far from being the performance king and even its SSD mode has had little positive effect. Just weeks ago we delivered EXT4, Btrfs, and NILFS2 benchmarks, but now there is a new release of Btrfs available. Committed to the Linux 2.6.31 kernel was Btrfs v0.19. Does this release bring any performance improvements? Yes and no.

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

[bnolsen]

Based on my recent experience linux just needs a stable filesystem with a fast fsck. The setup has ~60 servers, most with 7TB and greater processing lots of imagery (the type that may populate google maps/earth) using both network and local access The only filesystem to run without catastrophic data loss or requiring system reboots due to filesystem lockups is reiser3.

Its performance with large files is less than stellar, but at least it is stable.

[kraftman]

Based on my recent experience linux just needs a stable filesystem with a fast fsck. The setup has ~60 servers, most with 7TB and greater processing lots of imagery (the type that may populate google maps/earth) using both network and local access The only filesystem to run without catastrophic data loss or requiring system reboots due to filesystem lockups is reiser3.

Its performance with large files is less than stellar, but at least it is stable.

You should warn all those dozens of people using Ext3, because they're probably unaware of this...

[aaaantoine]

When starting by compressing a 2GB file using Parallel BZIP2, the results under the Linux 2.6.31-rc2 kernel with Btrfs v0.19 were actually worse than when using the latest stable kernel with Btrfs v0.18. Btrfs v0.19 was about 15% slower. However, due to the different kernels, it could be directly related to either the Btrfs file-system changes or something else to do with the disk sub-system, as we noted in our early Linux 2.6.31 kernel benchmarks there have been a few sore spots.

I stopped reading here. These benchmarks are meaningless without a stable kernel.

[Gentooer]

Maybe I missed it, but was the drive even mounted in SSD mode?

Also as far as the different kernel versions, couldn't you have backported .19 to the 2.6.30 kernel? This would have been a much better comparison.

[bnolsen]

You should warn all those dozens of people using Ext3, because they're probably unaware of this...

Dozens of people don't geometrically and radiometrically process imagrey that processes substantial portions of the US each year. All those servers are constantly processing and moving data.

ext3/4 has huge problems with availability. A large raid array that has to go down for fsck (and it happens) is unavailable for almost a day. Basic reiserfs fsck is very fast, rebuild tree is slow but still substantially faster.

Yeah this stuff is sort of off topic, the state of stable linux filesystems hasn't improved much in the past 7 years.

[kraftman]

Dozens of people don't geometrically and radiometrically process imagrey that processes substantial portions of the US each year. All those servers are constantly processing and moving data.

ext3/4 has huge problems with availability. A large raid array that has to go down for fsck (and it happens) is unavailable for almost a day. Basic reiserfs fsck is very fast, rebuild tree is slow but still substantially faster.

I'd love to see fsck faster in reiserfs then on ext4. I wonder why you don't use xfs for such stuff?

Yeah this stuff is sort of off topic, the state of stable linux filesystems hasn't improved much in the past 7 years.

This stuff is sort of trolling. You should at least give some proofs, because it's just meaningless (it's possible problem is somewhere else, but ext just triggers it) and you should wrote about this at lkml. Aren't you afraid using Ext4? It's quite "new'

[ken_lewis81]

Maybe I missed it, but was the drive even mounted in SSD mode?

Also as far as the different kernel versions, couldn't you have backported .19 to the 2.6.30 kernel? This would have been a much better comparison.

++ Please re-run the tests with the appropriate mount option:

-o ssd

It may be difficult to graft the 0.19 tree into the 2.6.30 stable kernel; but it would stop there being any possibility that any subsystem changes could cloud the comparison of the two versions of btrfs. On the flip side, btrfs is part of the kernel and in sync with the kernel versions, and few enthusiasts at Phoronix are going to roll their own backported btrfs-0.19 version of kernel 2.6.30: you'll user a vendor-supplied or mainline kernel with the matching btr version. That concession stated, I'm in favour of the backport because, well... let's please pretend to be scientific...