I've quickly skimmed the discussion on fedora-devel regarding btrfs. I wondered mainly how they'd handle the various cases where btrfs does not work well, e.g. files that change often inline (databases, VMs, etc). Apparently an application can tell to treat those files differently. So it's basically a matter of fixing various software to work nicely with btrfs as well as any similar filesystem.
As mentioned in the thread, openSUSE already uses btrfs for loads of years. I do wonder why it isn't more supported by upstream software (postgres, VM things, etc).<p>I was also surprised how good the discussion was on fedora-devel. It seems that people didn't break into camps of "over my dead body", and "if we do not do this I'll leave", etc. It seemed more like a "this is my really thought out proposal, but is it actually feasible or did I forget anything". Then people raised problems, sometimes the proposer(s) already had a solution, sometimes it was something they didn't think of. What's nice is that despite seeing various problems everyone seemed to understand that people are trying to improve things.<p>I didn't read fedora-devel for many years so that was a welcome change over the past.
btrfs has made some headlines in the past about its severely broken checksum computation in RAID modes, which rules them out for production use, i.e. <a href="https://phoronix.com/scan.php?page=news_item&px=Btrfs-RAID-56-Is-Bad" rel="nofollow">https://phoronix.com/scan.php?page=news_item&px=Btrfs-RAID-5...</a><p><i>The wrong parity and unrecoverable errors has been confirmed by multiple parties. The Btrfs RAID 5/6 code has been called as much as fatally flawed</i><p>It would be interesting to know if this has been addressed already.<p>The big fat red warning on btrfs' own wiki page is not inspiring trust either: <a href="https://btrfs.wiki.kernel.org/index.php/RAID56" rel="nofollow">https://btrfs.wiki.kernel.org/index.php/RAID56</a><p><i>For data, it</i> should <i>be safe as long as a scrub is run immediately after any unclean shutdown</i>
For desktop use, what problem does btrfs solve better than lvm+ext4?<p>Btrfs is slower than lvm+ext4, doesn't like working with large files, requires more ongoing maintenance (scrub, rebalancing), and is more prone to data corruption. Given that lvm can do snapshots under ext4, the only real benefit of btrfs is btrfs send, but for most use cases that doesn't seem like a large enough benefit to be worth the rest of brtfs' drawbacks.
Interesting - As RHEL is downstream of Fedora, I thought BTRFS was not being explored further by Red Hat, on account of their deprecation of it downstream in RHEL.<p>If I recall this was because they didn't have the developers able to work on the software, preferring to use XFS + LVM to accomplish some of the goals of BTRFS as their STRATIS project.<p>I wonder what this means for RHEL going forward in RHEL 9?
A few points:<p>- No this doesn't affect RHEL.<p>- It's only for Fedora Desktop spin (which for various reasons including this, but also others, you shouldn't use even on a Desktop - I install Fedora Server on my laptop).<p>- Only a subset of btrfs features will be used, especially avoiding the ones which are known to be problematic.
I have no issues with BTRFS, apart from the documentation is really poor.<p>I don't mind it becoming popular, but please for the love of $Deity can we please make the docs as good as ZFS. I will contribute cash if needs be.<p>Facebook are utterly shit at documenting things, so yes it might work for their usecase, but they essentially store knowledge through Shamanism, which is terrible unless you're inducted into the world of the spirits.
It’s funny that fedora is moving to supporting btrfs as the default FS, when red hat has stopped supporting it altogether. I’m a big fan. In a world where we can’t have GPL compatible ZFS, btrfs is the next best thing.
There's probably no way to convert the legacy ext4+LUKS filesystem over, so, I guess I'll decide when F33 comes out whether I want BTRFS enough to do a clean install rather than an upgrade.
> The switch to Btrfs will use a single-partition disk layout, and Btrfs’ built-in volume management. The previous default layout placed constraints on disk usage that can be a difficult adjustment for novice users. Btrfs solves this problem by avoiding it.<p>good call, subvolumes came to the rescue of the /home partitioning. It's useful, but the inflexibility was in the proper split of available disk space. Novice users then saw warnings for /home - when there was still plenty of space on the root partition.
It's painful to see how much disinformation (even in subtle ways or to go off the rails) some topics are getting in here.<p>If you want to get a better picture, also about Zfs and Fedora, read the previous Btrfs threads where the developers took the time to discuss it. And to kill some FUD.<p>I have no association with Btrfs or Fedora but I'd like to have a modern FS in-tree as battle tested as it can be.
I just herd my roommate saying "i don't want to play too much with my amd cpu overclocking because if i crash my system too much btrfs might get corrputed again".<p><i>laughs in zfs</i>