-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Sun, 2020-06-28 at 10:21 +0000, Antti 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.
In one of the other messages in this thread, people from openSUSE has
said that they started to receive less bugreports when switched from
btrfs(root)+xfs(home) to just btrfs(root+home).
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.
What benefits zfs has over btrfs? Esp. when it is not part of the
kernel, people in Fedora do not really have much experience (neither
expertise in development).
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.
Snapshots in Btrfs are working quite well, what exact features you are
referring here to? Also note that we are not planning to offer any
features that are not stable. We are planning to offer what btrfs
provides as default.
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.
Do you have some link to the bugreport about this?
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.
Well, I hope people don't run random commands from the internet? Myself
I did not even need to run anything like that.
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.
Upstream is working on that.
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_complica...
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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 - --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl74lVoACgkQEV1auJxc
Hh6LNhAAu6OC9A3PngNst6Ym9Bfq2TlNwfTiwk0nJrOMleAQwhmAySmfVtv8YeQF
ozDYuPOqcLKDsSxrNKDzA+aaOegZpNnvTNB2UOFZgGQPdrTqGXv+kt3FCk9Vu0kF
6SW6DB83sgfuP93RJ7LDqktOw/EtCX4PWtRj1mSixTlpBqSQ3YPYHittgWnD/pWK
Ka4h4WrQVvpY6tS7rfCCk+Vc4QLMBy5cw7Og/TtrBBJ9jFU2pZbbJ6wDKFMOC6l6
wr65un/9FuwKY9o8DGaqePTezVijTVumXfrAjtkfsvpxze2CJKCOC3r9+GQjWXmK
WszsZ4tBJuoHrndINHTOronOsBrj3UoRkMqnCThu5JqMMqo0+9EsqewjbtCJYD7U
gAYAT2neHzWKaNM3rl9hxOj1vkiwaLFiwYkDAmfwwaPJ5DH5FsjACevXj03E6zNn
WwHZTHR1pi3SogU08wY0WszBrkemEBkwD7tbA5VZPtXSyAe/ae0qJsWfB4f/ebqf
JDoTlbctYMAQ5HCTIE+d0n4U7XiBUcXGvN4Eb+mej+fqQwVdUKz0XYUdLFfDthef
YCH+8WEz9ej9W2TGnB/1gjPK+1U6GllF5O2jJQmS/qYQgVk1oZsxnQg2e27HUswj
UdLOtVuRDZu46LndelTke/SxQXrW6+C+C6UVgy0t6sPenUIVvIU=
=MUeD
-----END PGP SIGNATURE-----