1. 23
  1.  

  2. 8

    I am taking part in this test day. My hope is that Fedora adopting Btrfs will add a lot of development power into Btrfs to make it more mature and iron out the kinks.

    1. 4

      Any links to high-quality discussion about this decision? When I last checked (a few months ago) Btrfs was still having issues stemming from poor code quality WRT compression. I took this as a sign to avoid for Btrfs for a while longer.

      1. 2

        There are some discussions running into developers list, and also this page: https://fedoraproject.org/wiki/Changes/BtrfsByDefault

          1. 2

            This is really exciting! It looks like many years of work shaving off corner cases of this complex file system have paid off and there are people willing to do the work required to integrate Btrfs into a workstation focused distro.

            The above wiki page and discussion thread are full of frank and pragmatic discussions about Btrfs. Prior concerns over Btrfs’ reliability was always anecdotal, but Facebook has data from millions of machines showing Btrfs to cause fewer issues than XFS on shitty hardware. The maintainers readily accept that Fedora will expose Btrfs to a wider range of hardware and workloads, but make a convincing case that Btrfs will fix more problems than it creates.

            As someone who has worked on tough projects with lots of unreasonable skeptics (DNSSEC) it’s nice to see that it can eventually pay off. Now if only I can get over my health issues and back to my long-term projects….

      2. 3

        I’ve chosen btrfs as my default filesystem on my openSUSE installation and now I’m trying to search for some free time to migrate away from it.

        Sometimes I’m doing mobile development (hobby projects) and btrfs is incompatible with Android emulator, at least on my machine. From some reason it works properly when using qemu through libvirt with e.g. Windows. But Android emulator is very choppy, completely not usable. However, after I’ve moved the guest system image to another partition with ext4, everything is smooth again.

        1. 2

          That’s because lots of random per-file I/O interacts poorly with CoW, you can disable it per directory. Ideally, the vmm would work with the CoW filesystem, or at least disable it for the specific file/directory. This will likely happen only after it becomes default on a major distro.

          1. 3
        2. 1

          how far along are XFS checksums and snapshots?

          1. 0

            If they were proposing a well-rounded FS with an emphasis on low latency, like NILFS2, I’d understand.

            But for some reason it’s Btrfs.

            1. 6

              I don’t have any expertise about this stuff, let alone skin in the game. But here are some factoids for the curious:

              1. 8

                Both filesystems support metadata and data checksums (AIUI, this is unlike the other Linux filesystems save out-of-tree ones like ZFS), which to me is a requirement. Silent data corruption is horrifying.

                My rationale for strong preference for NILFS2 is that latency is pathological with btrfs, with i/o stalls aplenty in workstation usage.

                NILFS2 is optimized for latency. It does have worse throughput, but nothing too bad or pathological. In a workstation scenario, having somewhat less throughput is less likely to result in UX degradation than i/o stalls.

                The popular ext4 and xfs also suffer greatly from occasional i/o stalls, but in btrfs they are frequent to the point of irritation.

                1. 2

                  eeeeh… btrfs in my experience is already pretty bad for throughput. If NILFS2 is worse than it I’m sort of wondering what we’re doing wrong. However, that might be mainly due to the aforementioned I/O stalls, so, I dunno.

                2. 6

                  If those NILFS2 caveats are up to date, that would be a nonstarter for Fedora. No xattr support means no MAC (SELinux).