Linux 3.15 SSD File-System Benchmarks

[phoronix]

Phoronix: Linux 3.15 SSD File-System Benchmarks

Now that kernel development activity is settling down for the Linux 3.15 kernel, here are some benchmarks of the EXT4, XFS, F2FS, and Btrfs file-systems compared to the stable Linux 3.14 kernel performance.

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

[Caleb]

Does anyone have any information on that 3.13 I/O regression? It looks like it wasn't fixed... or is the current low performance the new baseline?

[Viper_Scull]

I'm going to have to try XFS with my SSD. The performance gain in the last year has been off the charts.

[Azrael5]

what about 3.13 current kernel?

[zanny]

What the hell, btrfs? How is it still 30 - 40% slower in everything?

what about 3.13 current kernel?

They were published at the end of last year:

http://www.phoronix.com/scan.php?page=article&item=linux_313fs_hdd&num=1

[rikkinho]

is eol

what about 3.13 current kernel?

kernel 3.13 is already eol

[Azrael5]

kernel 3.13 is already eol

My question concerns benchamrk between 3.14 and 3.15, above all F2FS file system. 3.15 seems to cause regression.

[name99]

What the hell, btrfs? How is it still 30 - 40% slower in everything?

It may be safer against failure (ie it actually commits data in order and as promised when these storage modifiers are requested) rather than other file systems which ignore those modifiers for speed?
Similarly they it (I don't know) compute additional info (eg per chunk hashes) to ensure end-to-end data correctness?
Or it may optimize for what the authors consider to be realistic workloads, whereas the benchmarks presented here test behavior that is non-realistic?

This is the problem with benchmarks that are simply presented as raw numbers with no background as to what the benchmark is testing, the relevance of the number, and the properties of the file system being tested.

[zanny]

This is the problem with benchmarks that are simply presented as raw numbers with no background as to what the benchmark is testing, the relevance of the number, and the properties of the file system being tested.

It is my impression, but I don't know if its a lack of a frame or reference (IE, an 840 Pro is already so fast I don't notice the difference between ext4 and btrfs in daily use even when there is one) or the benchmarks are just bad for btrfs when daily use suggests otherwise.

I'm pretty sure btrfs does asynchronous checksum computations to not bog down the bus during writes (ie, it will keep checksumming the file in memory even if it commits to disk). And the data overhead of extents and data structures is similar between btrfs and ext4, at most the only overhead is block references for CoW.

I use btrfs everywhere. But I do so under an expectation that future versions will be faster, more stable, etc. I'm just wondering if I'm missing some critical inefficiency in it that makes it inappropriate for high bandwidth usage (which all disks are moving towards anyway, so bandwidth issues would just be an ongoing problem). Especially since the mechanical drive tests for 3.15 just came out and put btrfs on par or ahead in almost all of them.