All, As a long time user of Fedora I have run into nearly all the same issues as mentioned below by Antti. btrfs is not ready to be default: https://news.ycombinator.com/item?id=14907771
On Sun, Jun 28, 2020 at 5:21 AM Antti <antti.aspi...@gmail.com> wrote: > Hello, > > I'm in total opposition to this proposal as a long-time Fedora user. The > btrfs is unstable and not ready for production. Most of what I'm about to > write is admittedly anecdotal but it's the only file system in Linux which > has actively and regularly caused me to lose data on desktops, laptops, > servers and even on mobile phones when I haven't taken precautions and done > regular backups. Something I don't have to actively do when using ext4 in > my workstations and notebooks. > > This has happened to me because OpenSUSE and Jolla's Sailfish OS use btrfs > as their default file system. I've tried using btrfs from time to time in > various environments to see how it's progressing. However there hasn't been > fixes for long-standing issues in btrfs when it comes to desktops and > laptops in years. Btrfs can still for example run out of its automatically > manager "metadata space" which it cannot recover from. Even the relatively > recent improvement in kernel 5.8 have already been proven to not improve > the situation much although at least the subvolume deletion failing over > lack of disk space is now handled slightly better. > > You could probably just ask the issue statistics from OpenSUSE and SUSE to > see how unreliable btrfs is in reality. I hypothesise that a large majority > of OpenSUSE users don't actually use the supposed default file system of > their the distro and instead opt to use zfs, xfs and ext4. > > I'm honestly in shock that this is even a discussion right now again. If > there is a legitimate urgent need to switch the default file system for > desktop and laptop users (and I understand why there is pressure to do so > since ext4 has a number of shortcomings), then whatever legal obstacles > there are blocking the use of zfs should be cleared and zfs should be used > instead. Canonical with their Ubuntu is already trying to do this through > use of OpenZFS. The xfs has started to have issues as of late but even it > would be a legitimate choice. > > The absolute first issue with btrfs in desktops and laptops is that it > requires active conscious maintenance from the end-users to avoid large > number of potentially disastrous situations as well as unconscious regular > automatic constant maintenance on background which consume the disks and > eat resources. Based on my experiences btrfs works best when you don't use > the features you supposedly install it for. It's snapshots are a great > example of that. Which is why I suspect that most btrfs "success stories" > are ones where the users don't take advantage of the btrfs' features or > have actively turned them off conscious of issues they bring up later on. > Using btrfs doesn't make using PC easier and instead does the opposite by > adding more work. Meanwhile zfs has reliable and working snapshots feature > which is in actual use. > > With btrfs the following is a very common situation: It's not too uncommon > for users to have their entire disks full or near full. Okey, users will > then delete some files, maybe few large applications, but in btrfs that is > often not enough. User has to manually then run btrfs-balance operation > with filters and it usually resolves the situation but it will start > happening more frequently until it's completely unsolvable for the end-user > without major external assistance or them performing a reformat. > > And what inevitably happens with btrfs root volume is that the system can > and will stop booting after period of "strange behaviour". Sometimes it can > be resolved in maintenance mode but usually the end-user then has to boot a > live environment, chroot their system, and clear all hopefully backup'd > large files if the system is not in read-only (or clear that obstacle > first), clear (most) snapshots, run btrfs-balance operation and do it very > carefully or the entire file system might be lost. This will take a very > long-time (ranging from 30 minutes to some hours and up to 3-4 days based > on my experiences) even on a relatively small SSDs (not to mention HDDs) > and it also will shorten SSD lifespan. > > If laptop is put into sleep mode without users noticing that btrfs is > running maintenance ops on background (and it often is), the likelihood > that file system will get corrupt goes up the roof. Something users can do > is use TLP and as a first aid set SATA_LINKPWR_ON_BAT=max_performance for > TLP which then will shorten the amount of time laptop can be used without > recharging. And this has been a standing issue at least since 2015 with no > real fix on sight other than "lol, stop using btrfs" like one commentator > at Reddit wrote. > > The btrfs-check is also a massive can of worms and it cannot be safely > run. At least not without reading pages upon pages of manual and becoming > an expert in understanding how btrfs works. Expecting every Fedora end-user > to do this is unrealistic in many different ways. > > The btrfs has no native encryption to my knowledge. However alternatives > such as zfs already has a trusted and reliable encryption used in numerous > FreeNAS installations around the world. > > And much of these issues and many more are straight up mentioned in btrfs' > own wiki pages at kernel.org where one of the most shocking admissions > is: "So, in general, it is impossible to give an accurate estimate of the > amount of free space on any btrfs filesystem. Yes, this sucks." > > Source: > > https://btrfs.wiki.kernel.org/index.php/FAQ#Why_is_free_space_so_complicated.3F > > And these are the brains before btrfs admitting this that there is no > solution for this. No amount of userspace tools developmen and UX/DE > integration is going to solve this for the end-users. > > Please, don't switch to btrfs. It is not mature. It is not > well-understood. It is not properly "battle-tested". It can still die on > its own. It's just a ridiculous meme file system. At this point it would > take me some decade of smooth sailing at OpenSUSE side to start believing > that btrfs is ready for prime time in my own personal Fedora systems. Even > 5 years of smooth sailing would give more faith in it. But as it stands I > have to strongly oppose btrfs. It's too much of a headache with no relief > in-sight. > > > -- > Antti (Hopeakoski) > > P.S. Sorry for this emotional nature of this message. But I really, really > like my Fedora and I really, really dislike btrfs due past highly negative > experiences with it (some of them happening to me as recently as last year). > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
