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 😂
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.
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.
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.
@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.
I know that these questions are tiresome, but I'm at a point where, once the metrics get put into Workstation at f43, I'm moving on.
While I'd like to do that with my current disk setup, I'll probably move back to #Debian, where I'd been for at least 15 years prior to moving to #fedora 4 years ago. I never changed my disk arrangement or fs configuration in those 15 years.
So the filesystem strategy is a long term investment in my view.
