EXT4 Still Leads Over Btrfs File-System On Linux 3.8

[rogerdpack]

compression

As a note, might be nice to mention that btrfs + compression can still be faster, in your benchmarks, viz: http://www.phoronix.com/scan.php?pag...10_btrfs&num=2

[ninez]

And where did I say that most people prefer Btrfs? No, I was saying that looking at whether one or the other system is faster without looking at the features is not what should be done. Using one or the other depends on what the person needs, and it's not just speed.

You do realize that i never made any comment about you saying 'most people prefer btrfs', right? ~ So why are you asking me 'where you said that'?? (that makes no sense dude).... and the second part of your comment I agree with and in no way did i say anything to the contrary.

[GreatEmerald]

it is quite silly to say EXT4 exists for (your) said reasons. Btrfs isn't even a 'production' file-system and is piss-pot slow. (and ask yourself; which is in wider use, and why is that? ~ and no, it's not just because btrfs is newer, it hasn't proved itself to be a viable replacement yet).

And where did I say that most people prefer Btrfs? No, I was saying that looking at whether one or the other system is faster without looking at the features is not what should be done. Using one or the other depends on what the person needs, and it's not just speed.

[ninez]

Sure, but you're replying to the wrong person. I was just pointing out that "a user" was generalising things, and even in the wrong direction. Of course there are circumstances where you might need EXT4, that's why it exists. But saying that the vast majority of users are using SSDs and require faster speed over data integrity is clearly not right.

No, I was responding to your comment NOT a user's comment.

it is quite silly to say EXT4 exists for (your) said reasons. Btrfs isn't even a 'production' file-system and is piss-pot slow. (and ask yourself; which is in wider use, and why is that? ~ and no, it's not just because btrfs is newer, it hasn't proved itself to be a viable replacement yet). I didn't get the impression that a user's comment was SSD exclusive (although he can correct me if i am wrong), because HDD tests would also show EXT4 wiping the floor with btrfs too. The fact is btrfs (while very promising) isn't ready for prime-time, so this is not really a case where EXT4 is there just as an option for those who need the performance.

cheerz

[GreatEmerald]

It's never good to assume / make such generalizations. For example, almost anyone using their machine(s) for things like multimedia / proaudio are certainly going to want (even need) the extra speed. ~ On my last 'fresh-install', i had the choice to possibly use btrfs - which i briefly attempted to use, only to find out btrfs didn't have the performance that i required and thus i ended up re-installing with EXT4.

I think it really depends on one's application / use as to whether or not they will choose any given file-system. there may very well be circumstances where someone would want to (consciously) sacrifice some data integrity for performance gains. (hell, that's even why EXT4 offers a number of options in these kinds of circumstances).

Sure, but you're replying to the wrong person. I was just pointing out that "a user" was generalising things, and even in the wrong direction. Of course there are circumstances where you might need EXT4, that's why it exists. But saying that the vast majority of users are using SSDs and require faster speed over data integrity is clearly not right.

[ninez]

I'm pretty sure that most of these people would rather prefer a safe file system over a fast one. For most people there is no need for additional HDD speed, not even talking about an SSD that was benchmarked here.

It's never good to assume / make such generalizations. For example, almost anyone using their machine(s) for things like multimedia / proaudio are certainly going to want (even need) the extra speed. ~ On my last 'fresh-install', i had the choice to possibly use btrfs - which i briefly attempted to use, only to find out btrfs didn't have the performance that i required and thus i ended up re-installing with EXT4.

I think it really depends on one's application / use as to whether or not they will choose any given file-system. there may very well be circumstances where someone would want to (consciously) sacrifice some data integrity for performance gains. (hell, that's even why EXT4 offers a number of options in these kinds of circumstances).

[GreatEmerald]

i contradict this statement. this comparision shows what is important for the VERY most users out there when they install linux and want to chose a good filesystem to work. while everything that was mentioned above is correct it is not what most people know and are interested in. they want the faster one with default settings (not while tuning it with unsafe settings).

I'm pretty sure that most of these people would rather prefer a safe file system over a fast one. For most people there is no need for additional HDD speed, not even talking about an SSD that was benchmarked here.

[ssam]

i am using btrfs 2x 3TB raid 1, which will soon be 3x 3TB.

also happy to sacrifice some performance for checksumming and redundancy. remember that the default single disk options do duplicate metadata.

interestingly on the btrfs homepage https://btrfs.wiki.kernel.org/index.php/Main_Page it claims that 3.7 had fsync speedups, and that 3.8 has many small performance improvements. is there some regression in 3.8 that has cancelled out the improvements?

[a user]

This comparison tells me nothing :-(

i contradict this statement. this comparision shows what is important for the VERY most users out there when they install linux and want to chose a good filesystem to work. while everything that was mentioned above is correct it is not what most people know and are interested in. they want the faster one with default settings (not while tuning it with unsafe settings).

if we wouldn't have such a test people would ask which one to chose, which one is faster bla bla. btrfs is not yet at the point for everybodys default use.

so i would say, this test is exactly what is needed, for the very most people!

[benmoran]

As everyone pointed out already, a real test would be a simple RAID1 test of ext4 over MD, versus BTRFS RAID1 with two disks. And perhaps a similar test with RAID5/6 since the BTRFS code is almost ready.

......
The big show stopper for BTRFS IMHO is that it does not appear to support hot spares. That's a major issue for anyone wanting to use RAID for work.

Another feature that I'm waiting on, that I don't believe has been implemented yet, is automatic removeal of failing drives from the array. A did a lot of testing on four failing drives in a BTRFS RAID1 array. BTRFS does an absolutely amazing job of recovering stripes when bad blocks are found. The problem is that there is no setting for kicking a disk from the array when too many errors are encountered (like MD has). If a disk is dying and a huge swath of sectors goes bad, BTRFS will just keep trying to read, and relocating blocks as it goes. This had the effect slowing my test server to an absolute craw, rendering it unusable. The good news is that this feature should be trivial to implement, and probably will once the RAID5/6 code matures a bit. I'd expect the hot spare code to also make its way it at that time.
Looking forward to it!