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).
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.
So, I'm asking questions because I'm curious and very probably ignorant. I'm not trying to pick a fight, make points, or get in a dick-waving contest. I also don't know how closely you follow btrfs development. I skim the lists from time to time, so if I'm telling you stuff that you already know, or if my memory is not quite correct, I apologize in advance. Also, if you notice this comment after the comment submission window closes, you can reach me at $MY_HN_USERNAME@gmail
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.
I've been using btrfs in my laptop on my OCZ Vertex LE [0] since that drive was shipping with the data-eating v1.0 firmware. [1] I'm also running it on my desktop, and in a force-compress multi-device firewire-attached configuration for a multi-TB Postgres tablespace. It has been many, many years since I've run into a data-loss issue of any kind, despite unexpected power-downs or other failures.
Now... if you're using Kubuntu 15.04[3], with btrfs as your root volume, know that system lockups that require a hard reset may well do something to the log that makes mount hang. Do this [4] if your "task is hung" backtrace looks something like the one in the wiki page, then btrfs-zero-log is the thing you need to do.
[0] The drive is still going strong and error-free, too! :D
[1] This drive is what taught me to ALWAYS upgrade the firmware in your SSDs, ASAP. :P
You can follow the btrfs mailinglists to see the stream of people coming in that hit a case where btrfs can't recover by itself. I've hit one myself that required a btrfs-zero-log "fix", but I'm not running Ubuntu.
You have been extremely lucky. Keep making backups, though.
