|
|
|
|
|
|
by cmurf
3400 days ago
|
|
|
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. |
|
|
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".