Back

@jrredho looks like it was deprecated in 7.4 and removed in 8. https://access.redhat.com/solutions/7020130

@mikes1988

Hmmm. So, I now learn that this has been the case for quiie some time now. I used #RHEL for quite a while---it was a requirement at work, but It had been several years since I'd done a clean install, so didn't look at this business. Not to mention I've been retired for four years.

Now, it's again been a few years since I've done a clean install of anything, but knowing this fact will make my next filesystem choice while doing so a far easier decision.

@jrredho if you're looking something similar to RHEL but with btrfs, you could try opensuse. The default root FS is btrfs, and that along with their snapper tool is brilliant for rolling back bad updates

@mikes1988

Thanks for that suggestion.

I currently use #Fedora Workstation and, in fact, have my root and home mountpoints on a btrfs-formatted partition. This true largely because I followed the defaults for the installation. This for for f33 as it was the last time I did a clean install.

I think my point was, if Red Hat don't trust the filesystem enough to put it on their money-making product, why should I? And why, exactly, is that the case?

@jrredho it's still the default root filesystem on SLES, so I don't think it's a stability issue. It maybe just isn't something that interests enough of the RHEL customer base, when the majority of them just want a stable, solid OS, without all the bells and whistles.

It was initially developed by Oracle, so maybe there's a trust issue there

@mikes1988

I think maybe they want that on a filesystem that is also rock solid. Apparently, they don't think BTRFS filesystems provide that?

@jrredho that's why I mentioned SUSE, which is another enterprise edition, which is equally as stable as RHEL. They seem to feel it's rock solid enough, just Redhat that don't.

I've used it (albeit not on production) for probably nearly a decade now and I've only had two issues. One was back in the earlier days and I ran a partition out of space. It was recoverable but awkward to free up space. Second was on an old old old HP Gen4 server, with a physical raid card. I think the cache battery has gone on it, and every time it's rebooted the filesystem requires recovery - this isn't a btrfs issue per se. Problem being, the fsck.btrfs utility isn't the right utility to run, even though on other filesystems it would be the first thing most would try. I remember some discussion about how fscking the filesystem can make issues worse, which wasn't great.

Think the perceived instability with btrfs was more around the tooling rather than the actual filesystem.

@mikes1988

I really appreciate this thorough response!

I've been using the filesystem with no problems myself. I confess to not knowing exactly the pipeline connecting #fedora to #RHEL, other than to know that there is one.

The fact that you and I haven't had problems is anectodal. Red Hat seem to me to be signaling that they're not convinced that there's not a problem somewhere. Or they just have a fair bit of corporate inertia. :)

It is not common to see problems with it on discussion.

@jrredho @mikes1988 I can't really officially speak for RH's filesystem folks, but the decision about what goes into RHEL involves a lot more factors than just "do we believe this filesystem is outright buggy". you shouldn't read btrfs's presence/absence in RHEL as a simple up/down vote on its likelihood to eat your data, it's not as simple as that.

@adamw

Thanks, Adam!

I can very easily see that that's the case.

I guess the thing that's bugging me is that the btrfs is not even included in the distro(s) as an option. It's not in their RPM repo set. At least that's what I *think* I've been finding. If that's accurate, it's pretty heavy prejudice.

@mikes1988

@jrredho @mikes1988 RHEL intentionally has as small a package set as possible, because every package in RHEL is a substantial cost to Red Hat. it has to be supported for ten years. There's been a strong focus in RHEL 9 and RHEL 10 development on not including anything that isn't necessary. RH's supported filesystem story is the whole stratis + LVM thing, so including an alternative one, from RH's perspective, is just a pure and substantial maintenance cost for no significant benefit.

@jrredho @mikes1988 in fedora we can ship the whole world because we don't promise anyone we're going to support it all for ten years, and nobody's paying us money so even not meeting the support level we 'promise' has no real consequences. for RH and RHEL that calculation is *completely* different. this is why RHEL's package set is so tight, and EPEL exists.