On 23/06/2020 16:55, Neal Gompa wrote:
On Tue, Jun 23, 2020 at 6:40 PM Robin Laing <MeSat@xxxxxxxxxxxxxxx> wrote:
On 23/06/2020 12:23, Neal Gompa wrote:
Hey all,
Chris Murphy and I are working on a change to switch Fedora's desktop
variants to Btrfs[1]. The plan is for all Fedora desktop variants to
switch over, which means both release-blocking desktops
(Workstation/GNOME and KDE) will use Btrfs by default going forward. I
expect this to be a smooth change, as Btrfs has been a
release-blocking filesystem for many years now (at least since Fedora
20) and has had OpenQA tests to verify its functionality for nearly as
long as OpenQA has been in use in Fedora for testing. And I've
personally been using Btrfs on all my Fedora systems (~5 physical
machines and ~100 virtual machines) since 2015 with no issues.
My expectation is that there should be no work for the SIG to do
(beyond me doing the work, of course). For all the words that are in
the change proposal[1], the extent of the change is to flip the
settings in Anaconda to use Btrfs by default on new installations.
I'm interested in hearing about your feedback on the change proposal.
I am excited about this, personally, as I think there's some serious
opportunity to collaborate with KDE upstream and our friends at
openSUSE on taking advantage of Btrfs features to make a smoother
experience.
Thanks in advance and best regards,
Neal
[1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
I tried BTRFS on a system and was happy until I had a problem that
couldn't be fixed and it made remote backups impossible. Our system
admin and myself tried to fix it and every time ended up at the same
point that everything suggested was a full rebuild of the damaged file
system after a reformat.
Are all the tools there now to fix all file system faults other than a
failed drive?
In the last few kernel releases, there's been a lot of work to merge
the things people did manually to recover Btrfs filesystems into the
kernel to happen automatically. Btrfs is increasingly able to
self-heal in nearly all situations, provided that some kind of
hardware fault does not exist (e.g. bad drive, bad disk controller,
etc.).
I don't remember the details of the problem as it was a couple of years
ago. I personally will avoid BTRFS until I know that there are fsck
tools available.
While searching I am still seeing many comments from last month that end
with stuff like this.
***
My advice:
Do not use btrfsck
Do not try to fix the broken partition
Make a backup in the simplest way possible, e.g. with dd
As @SleeplessSloth said, its usually possible to mount it read
only, and create a new partition with the files.
https://github.com/maharmstone/btrfs/issues/215
***
Archlinux has a warning about using Btrfs.
https://wiki.archlinux.org/index.php/Btrfs
Warning: Btrfs has some features that are unstable. See the Btrfs Wiki's
Status, Is Btrfs stable? and Getting started for more detailed
information. See the #Known issues section.
***
But for me, this is the most telling.
https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F
Is btrfs stable?
Short answer: Maybe.
***
From the above links, until at least in the btrfs.wiki.kernel.org it
should be classified as "Stable" before being a default file system.
Just my thoughts
Some of the features in btrfs were the reason I tried it.
The wiki definitely needs some improvement here. It's not uncommon for
the Btrfs wiki to get stale, and the wiki is locked down to prevent
spam attacks (it is, after all, kernel.org!).
It is true that btrfsck / btrfs check should be avoided in most
scenarios. This tool specifically aims to recover a Btrfs filesystem
at any cost, which is a very special case that should nearly never
happen. Btrfs' design also makes it so that you should not really need
this. The filesystem will automatically handle recovering in most
spurious error scenarios, as well as automatically restructure itself
to optimize for performance regularly.
There is also some more effort around providing more automatic failure
recovery features with a combination of systemd and btrfs-progs
enhancements for worst-case scenarios.
However, Btrfs *is* more sensitive to bad hardware than ext4/xfs, so
you may find that your hardware isn't as good as it purported to be,
due to the stronger integrity checking and greater sensitivity to
hardware-induced errors.
When we had Btrfs developers talk to us in the Workstation working
group meeting last week, they talked to us in-depth about these sorts
of things and gave us a good idea of how well it's worked for them at
scale (they have more instances of the filesystem in use in production
in their datacenters and their laptops than there are Fedora users in
total).
I'm reasonably confident that it'll do quite well for us, and I
believe that you shouldn't have to worry about situations like that
happening unless there's a hardware fault these days.
--
真実はいつも一つ！/ Always, there's only one truth!
Interesting comments and as others have said, I wouldn't use data center
systems for a good reference.
My machine was an older machine and there were no hardware issues that I
know of and it is a few years later on the same machine. HDD's are both
good. Machine is on a UPS.
As others have said in this thread, Fedora users don't want to spend
hours trying to diagnose and fix a file that won't delete because of
something within the file system. I didn't like it when everything I
read said I had to re-install my system.
I am trying to trace down two weird bugs in KDE that is frustrating
enough. Try doing it when you don't have all the time necessary to
trace it down.
For Fedora users, it should be safe enough that if something happens to
force you to do a cold, pull the plug shutdown, it should be easy to
recover with easy to use tools, preferable automatic on reboot. I admit
that I cannot remember the last time I have had to do that.
Before Btrfs is accepted as the default, there needs to be much testing
with pulling the plug on running machines and getting them up and
running in less than a few hours of work. Not Data Center machines.
Typical home, low power or high power machines.
Even though Fedora is a "testing" platform, it has to be reliable and if
the file system isn't reliable, then it will lose more users.
My reference for ease of use is my wife and daughter. If they cannot
maintain their machines with minimal help, then there is a problem with
the O/S. Presently, KDE on these machines is running much better than
Windows on my son's computer (he is a gamer).
If the wiki is out of date and the data is wrong, that doesn't help the
discussion either.
Robin
_______________________________________________
kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/kde@xxxxxxxxxxxxxxxxxxxxxxx
