why redhat abandon btrfs where SUSE makes it default.?
im interesting to know why redhat abandon btrfs where SUSE makes there default.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html
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.
Responses
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.
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.
There is a good thread on this exact topic here:
https://news.ycombinator.com/item?id=14907771
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.
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.
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.
https://unix.stackexchange.com/questions/279502/how-to-shrink-a-xfs-filesystem
Will Stratis allow this?
Curious and thanks, Joe
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.
Regards,
RJ
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 ?
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!