BZ#1039124 RFE: Allow /boot on BTRFS, tracker

Not a show stopper. Advantages of fixing: better space utilization, reflinks for kernel/initramfs (dedup), compression.

BZ#1415846 Atomic install boot loader fails with btrfs option

Is a show stopper. This is BZ#1289752 which has some commentary on what I think is causing confusion. Probably just skip to comment 9 and 10. Basically GRUB is getting confused about how things are being assembled, and maybe is related to bind mounts.

The good news is that a converted ext4 to Btrfs installation (to avoid install time bootloader confusion) does work with OSTree and all the overlayfs stuff. So I think making this work out of the box might not be much work.

A down the road optimization might be to rethink whether/how to use subvolumes. I'd rather see the installer not create them, and have OSTree manage them instead.

From the brand-new RHEL 7.4 release notes:

Btrfs has been deprecated

The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.

The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.

Red Hat will continue to invest in future technologies to address the use cases of our customers, specifically those related to snapshots, compression, NVRAM, and ease of use. We encourage feedback through your Red Hat representative on features and requirements you have for file systems and storage technology.

Btrfs has been deprecated

This is for RHEL. I don't really think this affects Fedora other than obvious issues related to RH employees having less time to work on related issues. Nothing prevents the community, including RH employees from enabling this, though.

Btrfs has been deprecated

This is for RHEL. I don't really think this affects Fedora other than obvious issues related to RH employees having less time to work on related issues. Nothing prevents the community, including RH employees from enabling this, though.

Yeah, just adding it for reference

Btrfs has been deprecated

RHEL depends on rather old kernels, and they have literally no Btrfs developers in five years, so it's a huge PITA to be constantly backporting to support something for ~10 years. This dilemma doesn't apply at all to Fedora.

Red Hat as benefactor to and beneficiary of Fedora, puts itself in a better long term position by encouraging more broad storage knowledge base and usage in Fedora. Fedora mimicking Red hat is the path to sclerosis, boredom, and irrelevancy.

If anything, Fedora should further encourage Btrfs usage where it makes sense. Aside from an install time fs choice, there are a number of ways Btrfs could help make for easier, faster, more stable live images, compose times, and user experience.

I am a Btrfs skeptic for reasons unrelated to RHEL, but I can buy Chris's argument here. :)

I am a Btrfs skeptic for reasons unrelated to RHEL, but I can buy Chris's argument here. :)

I'd go as far as suggesting btrfs shouldn't be the default in any Fedora Edition or Spin, but I can also see the value in Chris's argument. I'd doubly support it if I thought we had a btrfs developer presence that could handle issues, but aside from Chris and a number of other technically inclined users, I don't think we do. Certainly not from a kernel filesystem developer perspective.

There is always hope that group could grow, but at the moment it's only hope.

Adding to the list:
Include btrfs-progs in ostrees