Btrfs Coming to Fedora 33

by Chris Murphy and Langdon White


User data is the most important thing on a computer. Whether it’s source code for the next big release, family pictures, a music library, or anything else, you want it to be safe. Changing the default file system is not a change to make casually. The Fedora Project is changing the default file system for desktop variants (Fedora Workstation, Fedora KDE, etc), for the first time since Fedora 11. Btrfs will replace ext4 as the default filesystem in Fedora 33.

What does this mean for me?

Btrfs is a stable and mature file system with modern features: data integrity, optimizations for SSDs, compression, cheap writable snapshots, multiple device support, and more.

The switch to Btrfs will use a single-partition disk layout, and Btrfs’ built-in volume management. The previous default layout placed constraints on disk usage that can be a difficult adjustment for novice users. Btrfs solves this problem by avoiding it.

As a techie, you may have heard of bit rot, and memory bit flips. Data can be corrupted by a multitude of physical factors, even cosmic rays from the sun! Before an SSD fails outright, often it will return either zeros or garbage, instead of your data. Btrfs safeguards your data with checksums, and performs verification on every read. Corrupt data is never given to your programs, and it won’t replicate into your backups to be discovered another day (or year).

Btrfs uses a “copy-on-write” model: your data and the file system itself are never overwritten. This enhances crash-safeness. When copying a file, Btrfs does not write new data until you actually change the old data, saving space.

In fact, users will save more space when using Btrfs’ transparent compression. Compressing data reduces total writes, saves space, and extends flash drive life. In many cases, it can also improve performance. Compression can be enabled on an entire file system, or per subvolume, directory, and even per file. You will be able to opt-in to using compression in Fedora 33. And it’s one of the features we’re looking forward to taking advantage of by default in future Fedora releases.

Trusted

Facebook uses Btrfs on millions of machines in production. They compare its stability to ext4 and XFS (another file system available in Fedora). In fact, they use Btrfs to “improve” the quality of the consumer storage hardware that they use in production. Btrfs detects problems before the hardware fails.

(open)SUSE have been using Btrfs for many years now, including SUSE Linux Enterprise Server (SLES). You can’t imagine a company that provides support to customers shipping software that they don’t completely trust.

What’s next?

The Change is code complete, and has been testable in Rawhide as the default file system since early July. Btrfs has been explicitly supported in Fedora since 2012. This is expected to be a transparent change for most users, however it is still significant. Fedora will ensure we deliver the dependable and reliable experience Fedora users have come to expect.

Special thanks to: Ben Cotton, Michael Catanzaro, and the Fedora Workstation Working Group for contributing to this article.

FAQs and Guides Fedora Contributor Community Fedora Project community For Developers For System Administrators New in Fedora Using Hardware Using Software

117 Comments

  1. Finally as default – Wonderful!

    • Axel

      Full ACK, no more need to manually try to convince anaconda to accept my manual setup using LUKS and BTRFS which has been a rather painful experience for me in the past…

  2. Does ‘du’ command will report correctly the size of the BTRFS partition ?

    • BTRFS is a bit different in how that would be reported, and I don’t think

      du

      is the command to use. To see what the filesystem looks like, and how much data+metdata is being used you would enter

      btrfs filesystem usage [path]

      so for

      /

      I enter

      sudo btrfs filesystem usage /

      which tells me about that particular subvolume in pretty good detail. If I want a more condensed answer I use

      sudo btrfs filesystem df /

      . Remember that btrfs doesn’t allocate the entire disk partition to the subvolume, so the filesystem will grow into the available space as required instead of how ext4 would allocate everything up front.

      • Thanks.
        Most of people don’t know about btrfs and these specific commands to use if you want to check disk usage.
        That’s why the first time I used btrfs, I froze my system. I checked the disk usage with du but btrfs was storing metadata and quicikly my system was totally full.
        So I switched back to ext4 after this try (some years ago).
        Maybe Fedora should warn the user about these commands and the inadequacies of du and other commands to deal with btrfs.

      • Bill Chatfield

        The du command has to continue to work properly. Du is a standard command and should not depend on what file system is in use. Users especially should not have to learn separate commands for each file different file system they might be using. Can you imagine having separate ls, du, find, cd, pwd, etc commands for each of the different files systems: ext2, ext3, ext4, fat, fat32, ntfs, ufs, xfs, etc. That is the point of the file system abstraction, so that the rest of the system can work properly regardless of which file system you choose. So, if the du command does not work with btrfs it is a serious bug in btrfs.

        • Martin W

          Is it a serious bug in btrfs or just a yet missing feature in du?

        • David Sherratt

          Agree absolutely.

        • David Sherratt

          I agree absolutely with Bill Chatfield’s comment. “du” should work properly irrespective of the file system, and that should be ensured by the operating system providing appropriate file system abstraction.

      • LinAdmin

        Just one example of BtrFS not working as expected, and there are many more.
        If you have a Raid-1 with two disks, it is impossible to separate the two disk and continue using the data without Raid-1.

    • Generally, ‘du’ should report use and free space correctly. It starts to get tricky with snapshots and reflink copies. Both create shared extents. And ‘du’ is not aware of shared extents, so they get counted each time. The ‘btrfs’ specific command will provide more information, as Stephen mentions. And that way you can see exclusive vs shared usage per subvolume, directory, or file.

      • FeRD (Frank Dana)

        That’s great and all, but you all do see where telling people that they should stop typing

        du

        and instead start typing

        sudo btrfs filesystem usage

        isn’t really going to be reacted to with cheers, right? First off, checking disk usage shouldn’t be a privileged command. That’s nonsense.

        Second, commands like

        du

        are short on purpose. Systemd was one of the first changes where, as much as I’m on board with it, every command feels like writing a novel. Going from two letters to four words and a path is a bad change. It’s not just having to learn a new command, that’s fine. When disks changed to GPT partitioning,

        fdisk

        became

        gdisk

        , providing an equivalent replacement. If

        du

        doesn’t work, where’s the

        bu

        command to do the same thing — without

        sudo

        , and without Tolstoy?

        • Andrew

          Never thought about that before, but I’m in total agreement with command brevity and privileged access to check disk space

        • My recommendation is everyone be patient with themselves and each other. Each person is going to have a different comfort level, and a big part of the change is figuring out how much of the details to get into. And from personal experience, it’s easy to get super excited and just bite off too much detail at once. It’s an exciting change, but it has a lot of features, jargon, and idiosyncrasies.

          It’s intended to be a transparent change for most people, including the use of ‘df’ and ‘du’ which is what I use most of the time.

          Should ‘du’ grow the ability to display exclusive versus shared extents? Maybe, because Btrfs isn’t the only file system that can do reflink copies. So can XFS. But it might take time to discover when this is useful information, and how to display it.

          Also, there is a built-in shortcut for btrfs commands that’s not obvious. And when typing out commands in forums, it’s reasonable to always use the long form. But then if we always use the long form, no one learns about the short form. And each person is going to come up with their own short form, because all btrfs cares about is that your short form is unambiguous: i.e.
          btrfs filesystem du
          btrfs filesys du
          btrfs fi du
          btrfs f du
          Are equivalents. People get confused. It’s normal. Try to be patient.

          Also, I don’t need to use ‘sudo’ for directories I completely own the contents of; but I regularly find I’m using sudo when I don’t need to; because when I don’t use it, I get called out that I needed to, so I end up using it when I don’t. I think everyone runs into this catch-22. And sometimes it tries my patience!

          • FeRD (Frank Dana)

            I regularly find I’m using sudo when I don’t need to; because when I don’t use it, I get called out that I needed to, so I end up using it when I don’t.

            That’s the thing that worries me the most about the proliferation of commands that end up having sudo slapped in front of them — the more often people use it to run what should be everyday, unprivileged tasks, the more cavalier they become about handing over root permissions, and the less they associate doing so with a potential security risk.

            Between people putting sudo in front of every command “just in case it’s needed”, and “helpful” tools like winetricks and Bundler running sudo commands on behalf of the user*, who still reall even thinks of it as a privilege elevation anymore?

            More and more users are going to find themselves one day just cavalierly typing

            sh ./run-my-shady-malware-please.sh

            after downloading some sketchy rootkit script… and when it pops up a sudo prompt asking for their password, they’ll have already finished typing it and hit Enter by reflex long before they think to question why it needs root permissions,

            (If they ever do question it. I mean, why wouldn’t it? Everything needs root permissions now.)

            — (The Bundler/winetricks/etc. thing, though. ARRRGH. “FLAMES! Flames, on the side of my face…” They always justify it by saying the tool is just “prompting” for sudo. Which is a crap excuse anyway, but it’s doubly crap since they can’t possibly know how recently the user previously ran a sudo command. And if it was recent enough that they’re still within the credential-caching timeout — which is increasingly likely, for all the reasons above — then the user won’t be prompted to enter their password again.)

          • FeRD (Frank Dana)

            Regarding my previous comments about tools that take it upon themselves to run sudo, I will acknowledge that Bundler does at least use the -k flag to expire sudo’s credentials cache, when executing sudo commands. That’s “something”.

            Winetricks doesn’t even bother to do that.

    • Ed Grimm

      What does

      du

      have with reporting partition sizes? I hope you mean

      df

      .

      du

      is a standard utility that should not need to know anything about the specific filesystem. Everything it reports on is stuff that should be available on individual files via the stat(2) system call, but

      du

      is a bit more helpful in that it aggregates the data across a directory structure to provide concise output. If btrfs breaks stat(2), it breaks a lot more stuff than just

      du

      .

      df

      reports on partition file sizes. It’s also a standard utility, but it’s a bit more understandable if it has difficulty in dealing with a new filesystem. I still think it’s a problem if it completely can’t, rather than just doesn’t provide as detailed of a picture. Most of the time, I don’t need a detailed picture. I generally run

      df

      to get one number – either available disk space or percent of the disk used. Needing to use root access and sift through pages of output is absolutely the wrong direction.

      df

      is also useful when I’ve inserted a USB drive or a whatever the new port is on my computer that replaces the USB ports drive, as I frequently don’t even know what filesystem format is on there. If I mount removable media and go to check its size with

      df

      and that only gives the right value if it’s an older volume, that’s an issue. I’d say it’s an issue with

      btrfs

      rather than with

      df

      , because people should be able to make simple queries to find out how full their disk is, without root access, without needing to look at the filesystem type, and without needing an MS in btrfs to read the answer.

      I’d like to think that this is an issue that would be worked before I find myself installing Linux on a new system and it opts to by default give me this choice.

  3. Jatin

    I personally will not recommend btrfs because many wine games including blizzard titles wont run on btrfs as stated on lutris github. I use XFS for better large file performance than ext4 and also a has great features overall thanks to RH for that.

    • Robert

      Could you say which titles that would be? I’m using lutris on BTRFS with Starcraft 1/2, Diablo 3 and Warcraft 3 without any issues I’d know of.

      Also I really like the fact that I can have several copies of the games in different home folders/different user permissions without needing extra space (I only need to deduplicate my files from time to time).

      • Jatin

        Overwatch won’t run

        https://github.com/lutris/docs/blob/master/Overwatch.md

        you can see here it won’t run correctly on btrfs system there are few others.. However this might have changed now I am not sure but this was the case or maybe still is.

        • They don’t say why. Meanwhile “I use btrfs on Arch and doesn’t ran into any issues with Steam or Lutris” from 1 year ago.
          https://www.reddit.com/r/openSUSE/comments/b9mck8/doubts_about_btrfs_and_games_on_opensuse/

          If anyone wants to do some games on Btrfs testing during next week’s Btrfs test week, we can figure out if there’s a reproducer, why it’s happening, get the bug report to the correct developers.

          • dutchy

            I’ve run so many Wine games in the last 10 years from btrfs partitions, and never ran into a problem related to the file system. This strikes me as very odd, if Wine games do not work it is because of Wine (and after a while it gets fixed) or the GPU (driver/libraries), not due to the file system.
            Only legitimate issue I can think of is support for case insensitivity. Perhaps fragmentation for games that do weird things and heavily rely on timing (i.e. broken games). Or perhaps people are simply mounting btrfs volumes with noexec and putting their wineprefixes there?

  4. Kevin

    Will this happen automatically on upgrade from an older version?

  5. Andrea

    Upgrading from Fedora 32 to 33 will offer the possibility to convert from ext4 to btrfs?

    • Ondrej

      I dont think that automatic conversion is supported and all those scripts. Fresh installation is needed fro building it.

      • Andre Gompel

        In any case, I have never had a Fedora Upgrade without issues. (many over the years).
        Usually I do the “upgrade”… eventually run in some trouble, within one day or one month.
        In the worst case the system is bricked, but the /home directory (and other personal ones) are preserved, so a full reinstall is possible.
        Anaconda has still many issues, and (even Fedora 32’s) and custom install is far from easy (it used to be !).
        So make backups before upgrade… and even after.

    • As Ondrej noted, the conversion will not happen automatically. I was advised not to do it as it is not a very straight forward process.

    • There is an ext4->btrfs conversion tool provided in btrfs-progs, however it’s strictly a file system convert tool, it doesn’t create the subvolume layout we’re using in Fedora. And it doesn’t go through and update various “bits” like fstab, bootloader configuration, and initramfs. The resulting converted file system is otherwise valid, can boot, accept updates and upgrades. But it’s recommended to clean install to make sure you get the expected layout.

    • grepnyc

      I don’t see how it’s possible to convert a partition table and retain the data in-place.

      So , no. It can’t happen unless it’s a destructive conversion.

  6. William Whinn

    I’ve been using BtrFS for external storage for a while and believe it’s a solid and stable choice. I have one question though: what does this mean for Silverblue?

    Will this be based on BtrFS also? If so, I will most likely nuke and pave my machines on 33’s release and rebase to the next version on a per-release basis.

    Thanks Fedora team for a great OS and thanks to you for a great write-up!

    • Silverblue will also use Btrfs by default. All rpm-ostree, toolbox, and flatpak features you’re used to will work the same, regardless of what file system you use for the installation. For more container centric workflows, you’ll hopefully see some performance and efficiency improvements as a result of overlayfs automatically using reflink copies.

      • William Whinn

        Thank you for your reply. I have a full R development environment within Toolbox that I rely on with some fairly heavy loads going when building packages from source and such so any more performance I can squeeze out of it is appreciated.

        I think I will still flatten my current setup and use the new BtrFS config. Theoretically, I should be able to just rebase to the new release with that intact.

  7. Chris

    Given the RHEL / Fedora relationship I am keen to understand why RHEL removed BTRFS from future releases opposed to Fedora?

    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-btrfs

    • Osqui

      And regarding this…why hasn’t Fedora chosen Stratis instead?

    • I don’t have a direct answer. But my educated guess is: (a) RHEL uses one kernel version for the entire release (b) just like ext4 and XFS, Btrfs fixes and features development all happens upstream (c) Red Hat doesn’t have any Btrfs developers to backport those changes. They do have ext4 and XFS developers. And backporting is a lot of work.

      Fedora is in a position to get all of upstream’s features and fixes quickly, without having to be concerned about needing a Herculean backporting effort.

      • Tony Su

        BTRFS has a well known bug that shows up rarely only in “very large” disk arrays as a corrupted parity bit.
        No worry if your array is only 3or 4 disks. Since RHEL often deploys on very large disk arrays, it’s not supported at all.

        But some months ago BTRFS RAID was introduced as it’s own native software RAID which mirrors data across large arrays, thereby avoiding using any parity bit.

    • hammerhead corvette

      XFS is widely used in implementations of RHEL I have come across. It is very reliable, and very mature file system. Stability and reliability is key in that line of installs. Fedora not so much, but this could point to a future release of RHEL with support for itsince Fedora will have it moving forward.

  8. Robert

    Thanks a lot for this effort! I’ve been using Fedora on BTRFS for a couple of years now with basically the same layout as proposed (subvolumes for /home and /root) and it has served me very well, especially data compression and the possibility to copy big folders/projects/etc for free – sometimes very useful!

    I have one question: are there any plans to support native encryption on subvolume basis? My main interest here would be home folders when used with systemd-homed. Or are there other solutions for that?

    Also, I’d like to note that there are individual applications which do not handle subvolumes well – I personally ran into one with sysprof (https://gitlab.gnome.org/GNOME/sysprof/-/issues/34). But these will hopefully get resolved before or soon after the release 🙂

    • Btrfs native encryption, based on fs/crypto, a.k.a. fscrypt (file system level encryption, as contrasted with dm-crypt block level encryption) is being worked on. Once that happens we can do more planning how to take advantage of it.

      Subvolumes (and subvolume snapshots) are a dedicated file btree, with its own pile of inodes, which ‘stat’ will report as having its own ‘fd’. For most users they’re going to behave pretty much like regular directories. For developers they tend to behave like separate file systems. The truth is somewhere in between, and there may be some sources of confusion that need to be worked out.

  9. Klein

    Will my hard drive be switched to Btrfs, or can I choose to stick with Ext4

    • Ondrej

      afaik There is no stable auto conversion from Extr4 to btrfs.

      • orbatos

        Conversion is stable, and can be automatically done, but the resulting structure has some undesirable characteristics so re-copying data is preferable and it is not surprising they would avoid having the installer do this.

    • It will not be converted to Btrfs upon upgrading to Fedora 33. You’d need to do a clean install to get Btrfs, and it’ll still be possible to choose ext4 (or XFS) in Custom partitioning.

  10. Semaphore Williams

    Any news on when they release BTRFS 1.0?

    They still have features that ‘might not work’ or are ‘expected to fail’. Should be fine if you format using a wizard that knows not to turn all the features on, but are all fedora users like that?

    • Michael Catanzaro

      RAID 5/6 is still unstable, but that’s just not something that you can set up unintentionally. Fedora’s default setup will be simple and stable. See https://btrfs.wiki.kernel.org/index.php/Status for details on what else is not fully-baked yet, but also there’s no need to worry since you won’t stumble onto any of this by happenstance.

      • Cody

        I thought as much.

        Thanks for that. I do use raid5/6 and LVM too (though maybe that’s not relevant).

        This is one of the reasons I have stuck with ext4.

        I remember when CentOS changed some installer things to do with md raids and it was a bloody nightmare to get raid6 set up. In fact there are some minor issues still but nothing I could do about it and it suffices. I dread upgrading to 8 not only because of that but dnf and its appalling logging system.

        So it seems I will stick with good old ext4. Not that I was inclined to do that anyway with my set up and all the data.

    • Liam

      No they’re not, which is one of the reasons why “defaults” exist:)

  11. John

    I’m excited for the move to BTRFS, good news to all fedora users and THANKS to Fedora team for all their hard work.

    • Cody

      No.

      It’s absolutely NOT good news for ALL Fedora users. For me it’s a burden should I have to reinstall what with my disks set up.

      It might be good for you but not everyone.

  12. Sandor I Lengyel

    I had to switch from btrfs since I got file system corruption. It was all right for 3 years. Went back to ext5

    • Btrfs future

      While I also had to go back to ext4 from btrfs(couple of years ago) I still believe btrfs is the future.
      In my case it was Linux Mint with btrfs in LUKS volume – it turned out corruptions were happening if suspend was used when closing lid.

      • Michael Catanzaro

        Is there a bug report for this? If there’s a bug report, that’s something we would definitely want to look into.

    • Michael Catanzaro

      Experience indicates that btrfs filesystem corruption is almost always caused by a failing hard disk (or possibly bad RAM). Switching back to ext4 is likely to result in your files being silently corrupted, because ext4 does not checksum your data like btrfs does. The difference here is not that btrfs has corrupted your data, but that btrfs detects corruption where other filesystems cannot.

      If you experience further corruption after switching back to btrfs, please do consider reporting a bug to diagnose the issue, but be aware it’s almost always going to turn out to be hardware failure. This is more common than you might think. E.g. although not a filesystem problem, I just had to buy new RAM because my old RAM was marginal and was causing kernel oopses and mutter crashes.

      • Anne Onymous

        If hardware failure does occur and corrupts a file, what is the process for recovering what is still left of that file? In a simple world, one can read around bad blocks and at least recover the rest of the file. Will btrfs allow that? I’m especially concerned about that with regard to compressed files. Will a bad block in the middle of a compressed file mean the entire rest of the file is unavailable? Same with copy-on-write. I want the ability to create a physically distinct copy of a file, otherwise identical, to ensure that a bad block in one copy does not automatically corrupt other copies. Disk space is extremely cheap these days. Therefore, de-duping holds no attraction for me.

  13. Lucas

    Good news! I am excited about this change.

  14. Stephen

    I don’t know … hopefully, this will work out well.

  15. Phoenix

    As Semaphore Williams pointed out about pre-v1.0 status, I wonder if such a move would not be too hasty. I mean, I welcome change, but I hope this one is well planned and does not leave the uneducated users hanging high and dry.

    Since I typically install the server version of Fedora and then, if needed for that particular system, “upgrade” it to Workstation, I prefer and typically keep the default XFS choice over any other filesystem so far. Heard good things about it and never had any problems with it, like “unprovoked” filesystem corruption (a.k.a. FS failure without underlying hardware failure). The XFS tools are also pretty solid.

    That being said: I would welcome a comparison chart between ext4, XFS and BtrFS. Not a biased one, which you can find plentiful on the net, but something where it basically goes even down to how clean the code base of the filesystem is being written. While not perfect, but it would provide an indication as to how stable the filesystem actually may be under normal circumstances.

    • Facebook’s experience with millions of instances of Btrfs in production tell us that ext4, XFS, and Btrfs are in the same ballpark of reliability, and that ballpark is more reliable than the hardware they’re used on. And while they’re more fault tolerant than we are in Fedora, they aren’t infinitely fault tolerant. They aren’t in a position to just accept some ridiculously extra level of Btrfs specific problems.

      Btrfs has been a release blocking file system, as in “it must work”, for Fedora installations since circa 2010. And we’re using the same layout, mkfs, and mount options that have been undergoing that amount of testing. A default file system should get more scrutiny, that’s completely reasonable, as is using a file system that you know fits your use case better.

  16. Dick

    I stopped using btrfs with Fedora. I experienced bad performance (with disk images) and mirroring didn’t work without any warning (luckly I found out in time before any disks failed).
    I also had trouble when I ran out of disk space, unable to fix this by removing files (I had to rebalance).

    You have to be really cautious with snapshots (to remove them). They can eat a lot of diskspace and I couldn’t get an overview of diskspace used by snapshots (and where they where located).

    For those diskimages I’d recommend to use chatt +C to enable “nocow” mode, that improved a lot in performance for me, but switching back to md/ext4 really improved a lot for me.

    • Libvirt will by default set chattr +C on the enclosing directory for VM images for Cockpit, virt-manager, GNOME Boxes, and virt-install. So users won’t need to worry about this.

      There is no automatic snapshotting regime in Fedora 33, so users can opt into snapshots at their own speed, or not at all.

      Btrfs is slower at some things and faster at others. If you experience unusual behavior, let us know, there are straight forward ways to do A vs B testing and track down performance issues.

  17. Michael H.

    OpenSUSE don’t use btrfs for /home, they default to xfs. Why is that, and what makes Fedora different in this respect?

    • They use Btrfs by default for /home since January 2018 for Tumbleweed, and May 2019 for Leap 15.1.

      https://rootco.de/2018-01-19-opensuse-btrfs-subvolumes/

      • Michael H

        That’s the case if you choose to just have /home as a subvolume of /. If you choose to create a separate partition for /home, or create any other kind of “data” volume, both the OpenSUSE installer and post-install partitioner defaut to XFS.

        I presume many people with non-trivial sized /homes would like an option to place it outside of /. I’ve not seen a recent definitive arguments why XFS should be preferred for data over btrfs. I have read there might be some performance/maintenance issues with multi-terabyte file btrfs file systems, but it’s difficult to find out whether these issues are still current. I also read of some issues with some games.

        The other issues that arise with btrfs for root is moving file systems around is not as simple as it was. For example, when you consider simply relocating a filesystem using rsync -a -HAX, it’s turns out to be a bit complicated (admittedly, it could be argued old habits need to be thrown away).

  18. harry Anderson

    Maybe this is a bit early. In my experience I couldn’t get Fed 31 installed on my PC using btrfs as it thinks that the (UEFI)boot partition is on also on btrfs and complains. Works fine with ext4

    • I’m not sure. I haven’t seen that and I’ve done a lot of Btrfs and UEFI testing over the years. I’d be concerned there’s a stale Btrfs signature on that boot partition that didn’t get wiped for some reason.

  19. Matt

    Will the three proposed optimizations make it for F33? And particularly for the first one will /boot be its own Btrfs volume or will it be a subvolume along with the others?

    Thanks! I look forward to the new filesystem layout.

    • None of the proposal’s options are making it into Fedora 33. It will use /boot on ext4, and combined / and /home on Btrfs, each on their own subvolume. This is the same scheme available in Anaconda, the Fedora installer, for ~8 years. It’s really well tested. There are ~64 changes in Fedora 33, and we’ve decided to leave these extras for a future Fedora release.

      However, these are stable features that you can opt into for Fedora 33. We’ll have some kind of write up on how to do that. Stay tuned!

  20. Ken

    I never thought I would be one to exercise caution when trying out a cool new feature, but I have to say that my previous experience on back in 2015 using Btrfs ended very badly when it filled up the disk with these weird snapshot things. Except I couldn’t figure out what was eating up the diskspace without a lot of nonsense and frustration. When I did figure out the problem was these snapshot things, I did a ragequit and did a clean install with Ext4. Problem solved.

    I don’t know if this was a bug, or what have you, but this much I do know; XFS and Ext4 have been very, very solid and reliable as daily drivers for me for over a decade on a variety of hardware setups. There have been no awkward surprises or random software incompatibilities. There haven’t been any nasty surprises.

    Nasty Surprise Scorecard:
    Ext4: 0
    XFS: 0
    Btrfs: 1

    So…all I can say is…Btrfs burned me, and I’m probably going to keep using an inferior filesystem for several Fedora releases until the real-world kinks are worked out. And as a word of advice…please don’t turn on some insane auto snapshots stuff by default.

    I’m not a file systems expert. I’m just a tinkering enthusiast. I like some of the advertised benefits of Btrfs, and I want to be enthusiastic about Btrfs, but after already being burned once, I’m probably going to be content just hearing about everyone else’s adventure in Btrfs-land while having a calm, unsurprising life in the Isle of Ext4.

    • These are all valid concerns, and it’s completely reasonable to stick with what you know for now. Btrfs isn’t perfect, nothing is, and there are always trade offs. But it’s well suited as default because it transparently solves problems users run into (competition for free space between /home and / ) while also getting modern features, including always on integrity checking, reflink copies, and the option to use more features.

      • Ed Grimm

        So long as we’re talking defaults, I’m cool.

        My personal experience is of having more problems where I need to clear out my OS partition and reinstall because I know enough about computers to be dangerous, and I prefer to trying the stupid stuff out on my home computer before suggesting it for even the dev machines at work.

        I also like the idea of being able to install multiple OSes, and reuse my home partition for each. at one point, I had Fedora, Ubuntu, SuSE, Gentoo, and a few others all on one system, with the ability to switch between them without worrying about replicating my user data.

        Those aren’t standard behaviors, and I don’t expect they ever will be. Defaults don’t need to be able to support them. But it’s always important to be able to change the defaults for different end purposes, and a lot of reports of new functionality that will be set as the default fail to mention that they’re just talking about defaults, and that’s scary.

    • Michael Catanzaro

      We’re not going to be creating any snapshots by default. Seems like other distros have gotten into a little trouble by taking a bunch of snapshots and not cleaning them up. Fedora will simply not do that.

  21. hammerhead corvette

    I think it should be stated in the article that this will only affect those who do fresh installs of the OS, and exclude upgrades as many are assuming. The “File System” is a component most users wont have knowledge of directly and most coming from a Windows world won’t know of since it’s obfuscate to a degree from the user.

    On a personal note: I won’t be switching to BTRFS, on my next series of fresh installs and instead redeploy XFS. I tried LLVM for the last 8 months, for it’s snapshot feature, but it is very convoluted and hard to implement for novice/juniors. XFS works great with games as well. BTRFS for games on Steam and it’s previously poor RAID implementation are more reason for me to stay away from BTRFS.

    XFS “Just Works”

  22. Dagan

    Will this have any impact on the ability to use full-disk encryption like LUKS?

    Will this require any changes of options or commands used for Kickstart process, or manual installer?

    All my laptops currently have encrpyted disks – password required at boot. And this is a requirement to continue using Fedora for work also.

    • No impact on full disk encryption with LUKS. The “encrypt my data” option for automatic partitioning is still present and functions effectively the same as before, except you end up with a single large Btrfs file system on that dm-crypt device.

      Kickstart ‘autopart’ command default is defined by product definition, so it depends on what media you use the kickstart file with. But as long as you’re explicit with what you want, i.e. autopart –type=lvm –fstype=ext4 –encrypted … then that’s what you’ll get. But also autopart creates extra volumes and subvolumes depending on the type; and those defaults can change release to release.

      • Bruce

        This is not a BTRFS question per say, but an encryption question. I have a Trusted Platform Module (TPM) 1.2 in one of my systems and a TPM 2.x in my newer system. Can you point me to resources at RedHat or the Fedora community that handle the development of software that use the TPM to implement disk encryption? In my older TPM 1.2 system, I’d like to store my key in my TPM and not have to keep entering the LUKS password at boot time. I read somewhere that this was possible even though the encrypted file system exist already.

        I forgot to encrypt my drives on my new system, but I plan to reinstall everything with encryption. However, my wife uses this system and I don’t want her to have to enter an extra/new password in order to boot the system. She hates remembering passwords and I don’t want her to write it down either so I want to store the disk encryption key, or keys (plural) in the TPM.

  23. Amir

    Hi,
    So this change isn’t applied on Fedora CoreOS? Are there any plans to do that? How will it affect OKD?
    Thanks!

    • The change affects just desktops, so Fedora CoreOS is not included in this change. They use a different installer, called Ignition, and are planning to support the option to install to Btrfs.

  24. Jakob

    I love, and i hate BTRFS.

    But i had so bad experiences with BTRFS, that i removed it from almost all of my devices.
    I lost many times all my backups, because my external USB-HD with BTRFS produced broken Filesystem. Unrecoverable. It was only backup… But i lost the data. And this happened on different USB-HD with different Laptops… more than once…

    The other thing is, quota is not working. BTRFS gets really very slow, if you have quota enabled…

    • Yep, that’s rough. I’m not sure what happened in your case. Busted file systems are never fun. What I can tell you is, the disaster recovery story is different on Btrfs. There are multiple opportunities for recovery even when repair isn’t possible. This will be documented.

  25. Is there a reason to put /boot on ext4? On my main system (Fedora 32) I use Btrfs on / without separate /boot partition. On my notebook (Fedora 32 also), I do have a /boot partition, because / is encrypted (with luks): but /boot is on Btrfs.

    • There’s nothing wrong with doing it on your own, there’s been stable Btrfs support in GRUB since circa 2010. Even GRUB Legacy had Btrfs support.

      The main reason for leaving it on ext4 for now is resources and timing. In a narrow sense, it’s a simple and safe change. But it has all kinds of peripheral effects on other teams, other architectures, and the broad impact needs more discussion, design, planning, etc. It should be a deliberate change, to help Fedora do things that can’t otherwise be done, rather than changing it just because it can be Btrfs. There are a number of ideas to explicitly take advantage of it.

  26. Andrew

    I’ve been using btrfs for several years now on my home server, with 12TB spread over 8 disks on different mount points in raid-0 & raid-1 combos. I’ve never personally had a problem, but I feel a certain level of uncertainty over it’s stability based on what I hear on the Internet, and admittedly, some of those comments may very well be misinformed drivel, rather than real fact, but it’s comments like that which stick with you. I think one of the hurdles is going to be “perception” around it’s stability, and I suggest that one tactic to counteract this would be to make a big effort to clean up the wiki, make it up-to-date, and user-friendly and readable. Show that ‘someone’ is taking ownership of btrfs, because at the moment, I have no idea who the team is behind it. It doesn’t seem that there is a figurehead since Chris Mason left. Is there a team and/or figurehead for the project now, or just multiple “contributors”? I never go to the official wiki any more, I use Arch Linux’s wiki instead because it’s a lot clearer and more concise with more recipes in it’s cookbook.

    Even this last month, I got a new 6TB disc, and seriously considered over a few days whether it was going to be btrfs or xfs, and i’m a fan of btrfs. I find it really difficult to go back to xfs/ext4 these days because the checksum feature, compression and buil-in raid are killer features for me.

    But there are some drawbacks that I wish would just get fixed already:

    Built-in encryption: It is clunky to fix up LUKS then place btrfs on top. I wish it was just included in the fs. I wish all filesystems had this feature.

    RAID on a per folder or per subvol level: I don’t want to “waste a disc” in a RAID-1 when really, I only need certain folders to have that level of redundancy. Ideally, I would like most of my disc array (min. 2 discs) to be RAID-0 for performance, but with certain folders or subvolumes–im not bothered which–having RAID-1.

    There has been a lot of diffuse talk on the net of the ability to snapshot a subvol before a ‘dnf update’, and to be able to rollback to that snapshot if dnf fails for any reason, or you’re not happy with the result. Has anyone ever tried this? I’m not supper technical at this level, and this was above my level of expertise. All the articles that mention this ability fail to actually step through it. This leads me to the question: where are the tools for managing snapshots and subvolumes? Don’t get me wrong: im most comfortable in the terminal, but there is so much syntax to get that process working that it becomes cumbersome even for seasoned techies. If there was a GUI tool to manage this, it would be much easier.

  27. Frank Caviggia

    What happened to Stratis (https://stratis-storage.github.io/faq/)? Did Oracle give up their licensing issues here? What support issues would be in the upgrade path from Fedora to RHEL? It seems like XFS would be a better ‘default’ with BTRFS optional.

  28. Shy

    Recent patches to Blivit enable you to install Fedora with subvols named “@” for the root fs “/” and “@home” for /home. That enables you to use the timeshift program in btrfs mode.

    https://ask.fedoraproject.org/t/timeshift-and-btrfs/5325/4

  29. Eug

    Sounds good, but want to note that I’m trying btrfs on one of my Ubuntu systems and am not really impressed by some usability aspects. For example, figuring out the disk space used by snapshots & subvolumes involved enabling qgroups (which took a really long time) and then using a third-party “btrfs-list” script. I still can’t figure out how to delete a snapshot.. Hopefully with this move by Fedora btrfs will receive more attention & improvement!

  30. dutchy

    This is great! Btrfs will be a major win for most home users, which really do not need the specialised performance of XFS at the cost of flexibility and integrity (unless you have extremely large directories and run databases on your notebook, only ever increase partitions and also happen to have a reliable backup+restore solution).

    Of course there are some downsides/gotchas:
    – cow/snapshots cause fragmentation so use SSDs for the OS (which you should anyway)
    – not being able to use different mount options for subvolumes (e.g., for different compression settings on / and /home) is a bit of a pity
    – probably should disable atime, but it is mostly useless anyway for home users
    – it should be easier to revert subvolumes/snapshots and preferably also undelete files/directories (even when there are no snapshots)

  31. bkdwt

    This is a great news. I have already testing Fedora 33 and BTRFS works like a charm. What Fedora 33 or 34 needs is give the option to user to edit fstab BEFORE the installation and enable ZSTD support by default, because actually if you set compress=zstd you can’t boot into the system because GRUB can’t support ZSTD on boot disk (Fedora developers forggot to enable this, I think).

    Another thing would also be to do as OpenSUSE does, creating the mount points automatically in @ and separated one by one, enabling snapshot among other things.

  32. FeRD (Frank Dana)

    I hate to say it, but it might be wise to rethink this part of the argument:

    (open)SUSE have been using Btrfs for many years now, including SUSE Linux Enterprise Server (SLES). You can’t imagine a company that provides support to customers shipping software that they don’t completely trust.

    Because, here’s the thing: I can totally imagine that. Don’t tell me what I can and can’t imagine. In fact it’s not even difficult, I can imagine it with no effort at all. So when someone’s claiming they can’t, I start to wonder whether it’s because they’re naïve, they’re lying, or they’re trying to flim-flam me.

    • Ed Grimm

      I don’t have to imagine it. I’ve used SUSE. It’s been about a decade, and I’m not trying to make any statements about what they do now.

      I don’t have to imagine it. I’ve used Sun. This was, of course, before they were bought by Oracle, since the OS company Sun no longer exists. I’m not making a statement about Oracle.

      I don’t have to imagine it. I’ve used SCO. That was before they were foolish enough to sue themselves into oblivion.

      I don’t have to imagine it. I’ve used Microsoft. They’re a lot better about supporting their products now than they used to be.

      I don’t have to imagine it. I can’t list all the companies who have made products I’ve tried, found lacking, and found the company wouldn’t support the product.

      Making the claim that we can’t imagine a company would release something they wouldn’t support sounds like you’re about to do just that.

  33. kalatehas

    Will we ever get btrfs back in RHEL and CentOS as well? I just wasted 2 days of my life migrating my archive to ext4 so it could be attached to my server and not Fedora PC.

  34. svsv sarma

    A good debate. This ‘BtrFS’ discussion reminds me of ‘NtFS’ of the old times. So many “FS” evolved , survived and adopted amicably since then. The Btrfs is no exception. Old is not gold any more. I am eagerly waiting for the release of F32 with BtrFS as, I am sure, the FS doesn’t make much of a difference for a simple Desktop user like me. Thanks Fedora.

  35. Steven

    Tested BTRFS for some time and really love it, however found quota implementation somewhat difficult and cumbersome. If quota were as simple and straightforward as in ZFS, i would have been using BTRFS for sure.

  36. Joe

    Will the update from 32 to 33 force reformatting to BTRFS?

    • No. Upgrades will retain the file system layout you have, same as before.

      The only thing that changes is the Automatic user interface path in the installer will use Btrfs. All the same options in Custom and Advanced-Custom user interface paths will continue to be available.

      If you want Btrfs, you’ll need a new clean installation (reformat).

  37. Colin Walters

    I think these articles aren’t emphasizing clearly enough that the change just affects desktop variants. The title should be e.g.:

    Btrfs Coming to Fedora 33 Workstation

  38. Mark Hahn

    it’s basically insulting to say “well, suse is happy with it, so…”

    did fedora perform some kind of analysis, since almost everyone knows someone who has lost data due to btrfs. is suse using it in some restricted context? are they using a bunch of extra patches? do they have their own stats on reliability across versions?

  39. Kurt

    Not sure I am comfortable with this one for an actual Workstation machine with multiple disks where I would want redundancy. To my knowledge btrfs still doesn’t handle mirroring/raid 1 very well in the case of a disk failure. Is it still the case that if I have a simple two disk setup as a btrfs mirror and one of the disk fails that my system won’t boot up in that state? This seems like a show stopper as that defeats the whole purpose of being redundant.

  40. AndreaS

    One question: currently on my laptop I am running fedora 32 on an external usb disk. Will this be still possible with Btrfs? If yes, will I have to modify the procedure to create a portable installation of Ferdora?
    Currently I just use a diskless installation of Virtualbox to launch Fedora live and install Fedora on an external usb disk.

  41. laolux

    Please document it well. I remember playing with btrfs and running out of free space. I do not recall what the issue was, but it was a hassle to recover. I could not even delete files because, well, no free space… So I ended up extending the filesystem to a usb drive, which gave enough free space that I could start deleting some unneeded files. Afterwards had to remove the usb drive from the filesystem again and then could continue working. Rather complicated experience and I think it would be better to have good documentation about it.

  42. Has the old DropBox inability to recognise and use BTRFS been fixed yet?

  43. NonSequiTourDeForce

    A bit confused, as RedHat has deprecated Btrfs recently:

    https://access.redhat.com/discussions/3138231

    So how comes that Fedora moves to it ?

  44. Vshadow

    An excellent entry would be how to make images or snapshot in Btrfs (how to use snapper)

  45. ‘I use Fedora 29/30/31/32 +BtrFS.
    Fedora 33 install normal update?
    or reinstall?

    • Vshadow

      You do not have to install the latest version since you are using it in my case too.

  46. yeeeees, let’s touch the future.

  47. useful information:

    dmesg | grep -i btrfs

    btrfs dev stats /

    mount | grep btrfs

    btrfs filesystem show /

    btrfs filesystem usage /

    compsize /home

    compsize /root

    btrfs qgroup show /

    btrfs subvolume list /

    Only HDD

    find /home -type f -exec filefrag {} + >frag.list

  48. Michael H

    If anyone is interested in doing some background reading, there is a paper on Evaluating File System Reliability on Solid State Drives which compares btrfs and other filesystems, a link to the PDF can be found here:

    https://www.usenix.org/conference/atc19/presentation/jaffer

    There is also the OpenSUSE wiki entry on btrfs recovery (DO NOT blindly run btrfs check –repair):

    https://en.opensuse.org/SDB:BTRFS

    It’s a good idea to actually play with btrfs in a test virtual environment and figure out how it works and how you might employ it. Subvolumes and snapshots add quite a bit of complexity to get one’s head around, I wrote up some notes on OpenSUSE’s earlier subvolume layout here:

    https://forums.opensuse.org/showthread.php/521277-LEAP-42-2-btrfs-root-filesystem-subvolume-structure

    OpenSUSE have since simplified the structure of the root file system, but my explanation of the basics of subvolumes and snapshots still stands.

    I feel I should also add something I mentioned before. On OpenSUSE, if you put home in a separate partition the partitioner will default to XFS – the reasons are not stated anywhere I can find, but it makes some sense given snapshots are probably not needed for data partitions.

    Lastly, detecting bit-rot sounds good, but shouldn’t a modern drive

  49. Bruce

    It looks like the du command needs to become polymorphic, but getting around the filesystem’s appearing to be always full will be challenging since BTRFS employs a design whereby it grows to fill its extent automatically.

  50. Brian Crockett

    Guys, This is a horrible choice. BTRFS has failed in unrecoverable ways SO many times…

    Please, for the love of Linux, don’t do this.

  51. Yerry

    What about other commands then du, I think about the many monitor commands, like dstat, iotop, vmstat, iotop, atop, … Will those commands give the right values?

    If not, how do I monitor my systems. Run 2 commands in parallel, btrfs stats and an other monitor tool and then merge the output? This is not 100% accurate.

  52. I just read about this in “Distrowatch”, from this article it sounds really good. Why did Red Hat drop support for it? … I think of Red Hat as the top-tier of Linux, or King of Linux. If Red Hat is based on Fedora, does this mean that Red Hat will resume support for Btrfs? … By “support” I don’t mean just technicians that can fix problems but also “support” to help improve Btrfs. … Oh, yeah, GREAT Magazine!

  53. If you’re interested in further discussion, refer to the Fedora discussions topic here:

    https://discussion.fedoraproject.org/t/btrfs-coming-to-fedora-33-continuing-the-discussion/22922

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions