The suse folks adopting btrfs says more about suse than it says about btrfs. I still remember in the past how I got tricked into believing ReiserFS (3, not the 4 that never made it into the kernel) was a good filesystem despite the broken fsck, the lack of defragmenting tools and many other issues listed there :
https://en.wikipedia.org/wiki/ReiserFS#Criticism
It was also the only time I've had a FS really eat my data after forced shutdowns (cutting off power).
They kept pushing ReiserFS as the default until 2006, 5 years after the release of ext3 which added journaling to the ext family of filesystems. Ext3 was a much better filesystem all around. Suse only switched to ext3 because of the controversy with ReiserFS's author and the uncertain future of Reiser4, not because they admitted that ReiserFS was bad.
I will not make the mistake of putting any worth to suse's words again. Doing it again with btrfs shows they really have a knack for going edgy with filesystems while absolutely no other linux distribution is willing to recommend btrfs.
I trust the Red Hat guys to show more care and this is what they had to say only a year ago about btrfs:
"The btrfs developers keep telling us that it's not ready, so we're following that. (From one of our storage exports: "Btrfs will be ready in two years. The problem is, that's also going to be true next year, and in two years....") We try to be first where we can, but not at the cost of data loss for users.
-- Matthew Miller, Fedora Project Lead"
Doesn't look good to me.
As long as RH or Debian do not start recommending btrfs one cannot give it consideration in good conscience.
One way to look at this is in what technologies each company has spent resources. Suse has more Btrfs developers than I can count on one hand. Red Hat has zero these days. Red Hat might have more LVM and XFS developers than I can count on one hand. So it stands to reason each company's output will be biased, they're going to support (development, QA, and tech support) the things they're spending resources on.
Considering a big chunk, possibly the single largest chunk, of upstream is Suse, and they use it by default for several years on both the opensuse and enterprise offerings, it doesn't really make sense at all that 'btrfs developers say it's not ready'. This just doesn't square. What's going on in my opinion is, neither Red Hat nor Fedora have the resources, nor are they willing to add resources, to triage Btrfs related bugs and therefore Fedora isn't ready for Btrfs, not the other way around.
Even Suse goes very light on what is supported with Btrfs multiple device stuff, by the way. Single device volumes, I've reported bunch of minor bugs, no data loss ever. Multiple device stuff is difficult to qualify: if you're familiar with the warts you're at a net advantage over mdadm and LVM RAID. If you're not and run into trouble, there are traps and Btrfs's claims of focusing on fault tolerance and ease of use can betray the user.
> it doesn't really make sense at all that 'btrfs developers say it's not ready'. This just doesn't square.
Just looked at this page: https://btrfs.wiki.kernel.org/index.php/Status and I can see how they would interpret that as "not ready". There a good number of "mostly OK" ones, one is unstable. With comments like "write hole still exists, parity not checksummed", "auto-repair and compression may crash ", and others.
It might be good enough for some but I can see many customers of Redhat would not want to trust their crown jewels to anything that stays "mostly OK".
