According to Red Hat, BTRFS is almost deprecated. Who will be the next ruler?
Btrfs has been deprecatedThe 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.
Probably the biggest argument for BTRFS besides snapshotting (which isn’t always desirable) is its auto-repair features.
Because I don’t keep up on the most recent file system comparisons, I rely on what is written and recently I remember some articles say that <considering the potential overhead required> BTRFS does an admirable job delivering fairly good performance while providing superior automatic repair (running integrity checks automatically) . There is <some> detectable latency due to the required overhead but if you want this extra reliability, the result is admirable.
Also, besides snapshotting, I recently became aware of the “restore” command which allows you to “undelete” or restore individual files or directory (maybe even directory trees) .
XFS on the other hand seems to be less focused on reliability and instead on performance. Snapshots and related can be implemented with 3rd party tools. Instead, a wide variety of features and options exist that can maximize performance which would be important to the Line of Business Production machine.
Besides, even ext4 has become very reliable without BTRFS auto-repair features.
And, XFS and BTRFS do have their own manual repair tools should a problem occur.
So,
I don’t see that BTRFS is going away because of what it can do and does, but for a Line of Business Production Server I definitely would lean toward XFS for its feature set, especially if I was deploying on a RAID that provides a substantial amount of fault tolerance.
Is it ok that XFS, EXT4 are very old and need to support old stuff? I think it can be like an .mp3 audio format. What modern stable FS do you recommend with an SSD? It should has good performance including optimized CPU/RAM usage to support it. And not bloat with files/clusters etc.
A reliable wheel doesn’t need re-inventing. If it does what is needed, no need to change for the sake of change. Ext4, XFS, and btrfs all support ssd trim. Make sure your partitioning tool aligns the allocations in an SSD-friendly manner for best performance.
Just because a fs has been around for a very long time doesn’t mean that it’s “old” to the point of being outmoded.
Both XFS and EXT4 have changed considerably since they first appeared and support additional features with performance enhancements.
I’m far from a btrfs fan but some context probably helps:
People are making a bigger deal of this than it is. Since I left Red Hat in 2012 there hasn’t been another engineer to pick up the work, and it is a lot of work.
For RHEL you are stuck on one kernel for an entire release. Every fix has to be backported from upstream, and the further from upstream you get the harder it is to do that work.
Btrfs has to be rebased every release. If moves too fast and there is so much work being done that you can’t just cherry pick individual fixes. This makes it a huge pain in the ass.
Then you have RHEL’s “if we ship it we support it” mantra. Every release you have something that is more Frankenstein-y than it was before, and you run more of a risk of **** going horribly wrong. That’s a huge liability for an engineering team that has 0 upstream btrfs contributors.
The entire local file system group are xfs developers. Nobody has done serious btrfs work at Red Hat since I left (with a slight exception with Zach Brown for a little while.) Suse uses it as their default and has a lot of inhouse expertise. We use it in a variety of ways inside Facebook. It’s getting faster and more stable, admittedly slower than I’d like, but we are getting there. This announcement from Red Hat is purely a reflection of Red Hat’s engineering expertise and the way they ship kernels, and not an indictment of Btrfs itself.
I guess the main thing to take away is that RH didn’t think they’d miss out by not getting devs to support btrfs integration. That, in itself, sort of indicates they don’t believe btrfs will play a significant role in the future.
Use ext4 for everything
A filesystem that continues to create snapshots like Btrfs, it seems that knowing that she is ill she continually supplies her medicines
As much as I despise that fact, when RedHat wants something to be a certain way in the Linux ecosystem, it most likely will. Add to this that they suffer from a severe case of the NIH-syndrome and have the cash and market power to pull it off; see SystemD and PulseAudio. They aren’t Canonical that tries to play it big but doesn’t have it to back that up, they actually can.
Hello friends just joined this community and looking for more new topics and discussions here hope you will join me soon.
Canada is one of the best destination for online casino game, If you are gambling lover and interested in play online casino game than only one country Canada should be your choice because there are incalculable quality online casino club that oblige Canadians.
That is why this sort of activities in Canada is very popular among the citizens and the tourists coming to enjoy the qualitative leisure. I would like to recommend here https://casinoonlineca.ca/ to get access to the best of casino gaming in Canada. Here you will find worthy gambling facilities of one or another kind in each province as it is legalized in this or that way.
I think BTRFS is a natural SSD eater, constantly writing itself, and recursively degrading the SSD.
Personally, my experience with BTRFS was disastrous. It was back in 2015-2016 I was almost convinced that it was a hardware problem. Data constantly getting corrupt. After I re-installed with ext4, I am convinced that it was BTRFS. Ext4 is still my go-to and I think RHEL wants BTRFS to prove itself before introducing it in literally red hat distributions and maybe they weren’t very happy with it.
I think BTRFS is a natural SSD eater, constantly writing itself, and
recursively degrading the SSD.
Personally, my experience with BTRFS was disastrous. It was back in
2015-2016 I was almost convinced that it was a hardware problem. Data
constantly getting corrupt. After I re-installed with ext4, I am
convinced that it was BTRFS. Ext4 is still my go-to and I think RHEL
wants BTRFS to prove itself before introducing it in literally red hat
distributions and maybe they weren’t very happy with it.
Hi
No SSD’s have been eaten here running btrfs for many years, OCZ,
Crucial and SanDisk ones… most new ones these days are 20GiB
plus writes a day, don’t even worry about it.
There are still a number of controllers and disks that are blacklisted
by the kernel for things like trim (Samsung are one due to possible
corruption).
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.3|GNOME 3.20.2|4.4.104-39-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!