I don't know how or why ext4 took off the way it did. ext2/3fs' dominance was somewhat understandable, it was the dark ages of filesystem architecture (akin to the dark ages of cryptography), and no one used math or science to definitively say something was better than another.
But in the age of ZFS, filesystems like XFS and JFS have proven themselves worthy to remain in the ring as non-versioning, simple filesystems. Their resilience (now, despite any known issues in the past) is beyond reproach, combined with their speed and performance (comparing apples to apples, not journaled to non-journaled) is where it should be.
Why does any OS/distro use extfs by default for new installations? I can understand ancient machines that upgrade from ext3 to ext4 to avoid migrating data to a new filesysystem/mountpoint, but for new installations?
It seems likely that btrfs will become default for most distributions within a few years.
Nothing compares to having decades of experience with an on-disk format, a fsck tool, etc. Ext3/4 has had the most users, therefore it will be the most trusted (bugs like this one notwithstanding). When you're choosing the distro default, you have to prefer reliability to performance/features.
Hm, I guess I just gave an argument for why btrfs won't become the default for another 5-10 years. We'll see!
That has seemed likely for the last few years. btrfs' adoption has been much delayed
Because it seems to be btrfs is counting their chickens before they hatch. Making predictions about very complex software before it is 100% feature complete is pure folly. Experienced programmers know that when a project is 80% complete, from a feature standpoint, that doesn't mean 20% of the work is left to do. In fact, it is usually that substantially more than 20% of the work is left to do. (I don't know if btrfs is at the 80% mark, but I've heard there are a lot of things left to implement.. it's just an illustration).
As you understand it, what things have yet to be implemented?
Compression support needs to be rewritten, RAID5/6 support is extremely new and likely still quite buggy, quota support was just rewritten, in general an unexpected powerdown will dump you in a recovery shell because replay-from-journal has thousands of error cases that aren't properly handled yet (this may take many more years to fix because it's too complicated) and what do you know, this isn't really acceptable for servers.
There are long standing bugs related to ENOSPC and new ones still regularly pop up, often related to the (fixed) separation of metadata vs data allocation. In general, disk space usage handling is awkward and integrates horribly with existing tools (df/du), especially when snapshots are involved.
Snapshot/subtree handling and deciding what gets automatically mounted in parent/child relations is pretty weird and the whole subsystem probably needs a rewrite.
Online dedup.
They probably also want to fix the whole extent design that causes random-access files to take up to N*(N-1)/2 disk space, where N is the original file size.
What's wrong with how compression works? From a user's perspective, you either set a mount option, set a bit on a file attribute, or explicitly call for compression with btrfs defrag. [0] If you combine the latter two operations into a single checkbox, this is exactly how NTFS handles things. What am I missing here? Also, I can't agree that modern[1] btrfs handles unexpected power cuts poorly. This just hasn't been my experience. I can, however, agree that log replay isn't complete and still needs work.
I can't speak to the ENOSPC bugs, I haven't run into any in a very, very long time. Some time after 3.14, btrfs got a pool of space called the "Global Reserve" [2] which was intended to address ENOSPC issues. Somewhere around that time, btrfs also grew a better btrfs-specific df function invoked with "btrfs filesystem usage". I don't make extensive use of snapshots, but the numbers I get out of btrfs fi usage almost exactly match the numbers I get from plain old df.
I'm unware of snapshot automounting. Can you help me understand what this is? (A brief Google search wasn't enlightening.) I agree that taking away the ability to have subvolumes outside the FS tree if you didn't set things up just right at FS creation time is pretty bullshit. That certainly needs reworked. Everything else in my limited experience with subvol management seems okay to me. What's seems strange to you?
Btrfs doesn't yet have built-in online dedup, but are you aware of dupremove? [3]
Can you give me a recipe to create an N(N-1)/2 sized random access file? I use BTRFS for some very small random-access databases and large pretty-much-append-only databases and haven't run into this behavior.
I have a couple of things to say about your other comment:
People generally don't write to a mailing list to say what a good time they're having with your software.
It's pretty shit that log replay isn't worked out yet.
I certainly* don't intend to stop making backups. OTOH, I've been "getting lucky" for five years straight while running a FS that many people regard as the most untrustworthy thing in the world on a drive that many people regard as entirely unreliable and untrustworthy. :)
Cheers!
[0] Conceptually, this makes a lot of sense, 'cause all defrag does is re-write the file. NTFS re-writes files when you request that they be compressed, too.
[1] "Modern" means btrfs from the past two years or so.
[2] Much like ext*'s reserved-for-the-superuser space.