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! _______________________________________________ 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
