With Linux 2.6.32, Btrfs Gains As EXT4 Recedes

[jafox]

Another thing is that if you aggressively tailor for performance you often loose other functionality. For instance, reliability. Who wants to use a very fast file system where your data is unsafe? I prefer a slow filesystem where my data is safe, and not subject to silent corruption and bit rot as all file systems are (except ZFS). Of course, if it fast, the better. But the point of a file system is that your data is safe. Better slow and safe, than fast and unsafe?

Well. 3D Video driver benchmarks for instance, some comparison articles try not to only measure frame rate, but also judge the quality. They provide side-by-side screenshots and such. Benchmarking HD video playback, they not only provide the raw numbers but try to subjectively talk about the quality of the presented video.

A filesystem benchmark suite, in my opinion, isn't complete unless it attempts to also index reliability or at least to subjectively mention it as a caveat. If number 1 and number 2 are seperated by microseconds, but number 1 increases your likelihood of data by a non-trivial amount, ... well.. you get it.

I like these phoronix benchmarks though since they indicate slowdowns or speed bumps as these filesystems evolve.

[kebabbert]

I'm tired of these tests where default options are used everywhere. What's the point? Show us the potential of these filesystems not just the fact that no configuration = crap performance.

I think the point of default options is because most users do not know, or are able to use the correct switches to get greatest performance. Only few people know which switches to use. Why not bench with default options, which everyone will use then?

Another thing is that if you aggressively tailor for performance you often loose other functionality. For instance, reliability. Who wants to use a very fast file system where your data is unsafe? I prefer a slow filesystem where my data is safe, and not subject to silent corruption and bit rot as all file systems are (except ZFS). Of course, if it fast, the better. But the point of a file system is that your data is safe. Better slow and safe, than fast and unsafe?

[blagishnessosity]

CFQ change in 2.6.33

I'm surprised it wasn't mentioned that the CFQ scheduler in 2.6.33 underwent a change to increase system responsiveness at the expense of throughput. This would significantly affect the benchmarking results if you are comparing them to results on previous kernels. In addition, CFQ optimizes file allocation for rotational media, however this is entirely unnecessary on solid state drives and just results in extra overhead. As I said earlier, it'd be better to use a different I/O scheduler like deadline or noop when testing SSDs. This would eliminate the extra variable of an I/O scheduler that changes each kernel release and would likely yield better performance as well.

[tmo71]

Please do not use SSDs on your reviews

SSDs access times are almost identical for all sectors, thus eliminating all allocation optimizations of modern file systems.

Access time impact is huge

AFAIK, the 'nobarrier' and 'data=writeback' mount options might have a performance effect even if you don't have a journal (Theo says that the 'nojournal' feature only disables the journal writes to disk and not the journal logic)

[energyman]

first test (dbench) looks like ext3 never hits the platter - no surprise since ext3 has barriers default off. Unlike reiserfs.

You guys should really stop looking at ext3. It is not a filesystem meant for serious usage. Just pretty numbers.

[phtpht]

Again. Strange comparison based upon Ubuntu system. Why?

It should be noticed, that Ubuntu Ext3 does not use barriers by default in order to look much faster. But this is big lie, putting users data into the danger!

Typical Ext3 speed on distribution, that care safety of users data, would be much slower in these graphs.

Ouch! This is lame at best. Editors please put a big fat flashy red warning on every page of the article that the tests are massively deceiving.

[kraftman]

No no, I mean please merge your posts if you're replying to more than one recipient in a row. For instance



edited: It prevents one-liners from "polluting" thread.

Ok, no problem

[reavertm]

Definitely.
What for? I think they're correct. Or maybe you meant to put EDIT: when editing them?

No no, I mean please merge your posts if you're replying to more than one recipient in a row. For instance

[...]

Yes, you're right

[...]

No, you're wrong

edited: It prevents one-liners from "polluting" thread.

[lordmozilla]

As far as I know, SSD mode is activated by default nowadays with btrfs. Are you sure it was disabled?

Anyways, here's my future predictions:

- btrfs will not be avaible with Ubuntu 10.04
- btrfs will be avaible as an option for Ubuntu 10.10 which ships Linux 2.6.35/2.6.36
- I will use btrfs with Ubuntu 10.10 and it will seriously rock
- btrfs will become the default filesystem and replace ext4 in most mainstream distributions in early 2011

Thanks. Want to share when the messiah will be down to greet us? It's a filesystem benchmark, what's that got to do with when ubuntu users will be blessed with btrfs? I bet you're one of these people that upgraded to Ubuntu xx.xx without even knowing what the difference was.

I'm tired of these tests where default options are used everywhere. What's the point? Show us the potential of these filesystems not just the fact that no configuration = crap performance.

[kraftman]

(you know - the point of making benchmarks is to deliver conclusion other than 'benchmark is inappropriate').

Definitely.

@kraftman
please edit your replies

What for? I think they're correct. Or maybe you meant to put EDIT: when editing them?