On Tue, Jun 23, 2020 at 3:56 PM Neal Gompa <ngompa13@xxxxxxxxx> 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 personally would throw out the datacenter numbers. Why? Through your whole email you keep saying "except for hardware failures" Datacenters tend to have lifetimes. Meaning that if a machine/disk is too old it get's replaced. Or at least put in the "when this dies it get's replaced." Datacenters are also much more uniform. If you 1000 machines, the odds are that at most you have 10 to 20 variety of machines and/or hard drives. One the datacenter I last worked at if you had 1000 machines, you had 1 variety. What Fedora, and especially desktop Fedora, has is variety. Variety on new, medium, and old machines. How many people on this list often get hand-me down machines from windows users and we throw Fedora on them and they work great. Why do they work great? Because most of those hardware errors, especially disk errors, are recoverable or not even noticed. > 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. > Did you count how many times you said "unless there's hardware problems" in your email. That does not give me confidence. Troy _______________________________________________ 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
