why redhat abandon btrfs where SUSE makes it default.?

Latest response

im interesting to know why redhat abandon btrfs where SUSE makes there default.


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.


Hi, I don't know the answer to your question. But maybe Red Hat decided to spend more time in the development of ZFS on Linux. I would appreciate it to get ZFS in an upcoming version of RHEL.

That's an interesting proposition. Unlikely, though, considering the licensing issues which have plagued ZoL to date.

To paraphrase the upstream opinion, btrfs has been "almost production ready" for many years now, but never quite got to the stage where it actually was ready.

In the meantime, many of the features that btrfs provides are now available via other more mature and stable storage technologies like ext4, XFS, LVM, etc. We've put considerable effort into improving these technologies to the point where current Red Hat offerings already cover almost the entire btrfs feature set.

If you have a specific need which btrfs meets but you believe the Red Hat storage offering doesn't meet, then as the docs say, get in touch. I see your account has a Principal Solution Architect assigned to it, they will be glad to hear from you and can discuss implementation with storage/filesytem engineering as required.

I guess the only reason i'm interesting in btrfs is the fact that its option to manage snapshots in a sub-volume method. as far as i understand sub-volume has the option to save storage when using snapshot like d-dup does, and xfs\ext4 does not work that way.

I am not sure of the details here, I don't work much in fs/storage anymore, but look into the capabilities of LVM snapshots.

Like I said, I'm sure your Principal SA would love to hear from you and help you work out a solution, or field a feature request if this is a need we don't meet yet.

There is a good thread on this exact topic here:

it does seem that there is quite a debate about this in some forums and it still not totally clear . thanks for the information you provided.

Another interesting article here discussing the potential Red Hat filesystem direction (Stratis). http://www.phoronix.com/scan.php?page=news_item&px=Stratis-Red-Hat-Project

I would take NTFS read and write support as a replacement! +1 for ZFS support.

Hello Kevin,

If you need NTFS RW and are able to use the EPEL repos the following is a good access article.


Thanks, Joe

For anyone still following this topic, you may have seen that RHEL 8 beta includes the new Stratis system for managing storage features. It uses existing technologies, which we feel are more mature and stable and reliable, to provide many/all of the features that btrfs/ZFS provide.

The upstream project has some docs located at: https://stratis-storage.github.io/

Our own beta documentation is located at: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/configuring_and_managing_file_systems/managing-layered-local-storage-with-stratis_configuring-and-managing-file-systems

Thanks for the info Jamie. Any idea whether this stratis thing is also a technology preview, and likely to be abandoned in a few years, or does it really have a good future. I don't like adopting things that are going to get ripped out of the distribution. That's one of the reasons I still prefer using plain partitions as opposed to LVM.

I haven't kept my finger on the pulse much here (storage/filesystem isn't my area) but as Jorg said below, Stratis is supported and we usually only move features to fully supported once we intend to keep them around.

LVM is definitely here to stay, it has been for over a decade. I think you could safely use LVM and be confident your volumes will be useable in the future.

And i use ext2 :)

Hello Jaime,

I see that Stratis uses XFS. I have switched to that for my personal use and we have used it in our shop for professional work. However, some of the folks I work with would rather we always deploy using EXT4 as XFS does not allow the shrinking of an LV on the fly, whereas EXT4 supports it.

As far as I know the only way to shrink an XFS formatted LV is to perform the procedure found here.


Will Stratis allow this?

Curious and thanks, Joe

Stratis likely relies on the underlying technology to support a feature, and XFS does not support shrinking as you stated.

Hi, I'm still following this topic and I will have a look at Stratis in the RHEL 8 beta if I find the time. I'm afraid RHEL 8 will be released until I could take a look. ;-)

Thanks for the information you provided. Joerg

I've used ZFS in the UNIX world and it's pretty nice.

Regarding btrfs, I did some very extensive reading on it, and concur that it's not quite production ready. That being said, I have one customer who has a 500TB (yes, terabyte) raid appliance that has been running long term with it (I always hate writing statements like that).

I like Jamie's point, that the upstream version needs to properly mature it. Thanks Pixel for the info regarding Stratis.



According to the RHEL 8.0 Beta release notes Stratis is not marked as a technological preview. It is only mentioned in the section 'New features'.

According to the documentation for the RHEL 8 GA release,

"Stratis is available as a Technology Preview. "

Do I read things wrong, but from what I read it appears that stratis gives you a zfs/btrfs like "we do lvm and fs in one tool look" but in the end you just mount plain xfs disks on possibly sparse lvm volumes or am I missing the point? Besides a new management tool, is there any new features in stratis like bitrot detection, subvolumes, deduplication, encryption of subvolume level, etc ?

My understanding is that at least dedup and crypto will be provided by dm-vdo in the future.

don't get me wrong. I think having a nice tool to make thin cached lvm with xfs easier for users to set up is a good thing. I just don't feel this is the same level as the features you get with e.h. zfs on linux.

Update to this ongoing thread. The release notes for RHEL 8 cites the availability of Stratis, but as a technology preview (you have to scroll down in the release notes). More docomentation on Stratis is here

One of the main features we use BTRFS is to remove any bit rot. RHEL8 does not have a means to address this. As devices have got larger it's now not uncommon to have a local filesystem spanning hundreds of TB's. It is almost a certainly that some of your data in this will be corrupt. The only two local filesystems I know that address this are ZFS and BTRFS. I also prefer its built in volume management. In my mind, LVM has become too complex and therefore more likely to suffer missconfiguration. We raise with our Redhat team but it the only suggestion they could come up with was to run Glusters!

Interestingly enough, Fedora will make BTRFS the new default FS on the system disk (see https://fedoramagazine.org/btrfs-coming-to-fedora-33/ for further details on this).

So maybe Red Hat will use this step to pave the path to use btrfs on the system disk from RHEL 9 onwards?

Redhat are looking increasingly isolated as the only major distro not supporting either BTRFS or ZFS. They still have no replacement for BTRFS . LVM still has the RAID5 write hole. According to the docs STRATIS does not protect against bitrot, even if it were available as an option.

I've still not seen any real justification for dropping it, particularly now, given the amount of support it is now getting from every one else. It smells of NIH. Come on Redhat, prove me wrong.

I would expect BTRFS to come back to RHEL? Otherwise I'm surprised that Fedora started to make it default. I see Fedora as RHEL's playground, right? On the other hand having RHEL putting resources into Stratis point to another direction. According to wikipedia some of the main contributors of btrfs are Linux Foundation, Facebook, Intel, Oracle Corporation, SUSE...a pretty strong team. Maybe RHEL and others should see it as the future fs?