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
Guru
2051 points
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.
Red Hat
10444 points
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.
Active Contributor
242 points
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.
Red Hat
10444 points
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.
Guru
6643 points
There is a good thread on this exact topic here:
https://news.ycombinator.com/item?id=14907771
Active Contributor
242 points
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.
Guru
6643 points
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.
Red Hat
10444 points
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.
Red Hat
10444 points
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
Guru
2051 points
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
Guru
16339 points
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
Guru
2051 points
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'.
Guru
3613 points
According to the documentation for the RHEL 8 GA release,
"Stratis is available as a Technology Preview. "
Active Contributor
194 points
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 ?
Red Hat
10444 points
My understanding is that at least dedup and crypto will be provided by dm-vdo in the future.
Active Contributor
194 points
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.
Guru
16339 points
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?
Does anyone know here if iSCSI under RHVH will see a establish LUN that has a BTRFS file system on a NAS?
(I hope I asked that question correctly )
Guru
16339 points
Hello Ervan, that might be rather unique, and if you're not getting replies to satisfy your query, I'd recommend submitting a case directly with Red Hat to get a prompt response.
Regards,
RJ
Did BTRFS features ever make it int the RHVH kernel since it was based on RHEL 7.x ?
Maybe the kernel due to the filesystem being enabled by default in the distro but the userspace tools won't be there. Check your RHEV (or Ovirt) release notes for mentions of BTRFS. I didn't see anything.
Looking at your original question, though, that might not matter:
Does anyone know here if iSCSI under RHVH will see a establish LUN that has a BTRFS file system on a NAS?
The RHVH host will see the iSCSI LUNs without regard to their file system. iSCSI is a block device protocol, and a file system is something that is written to a block device. If the VMs that the LUNs are associated with can handle the data then things should work. I know nothing of your environment but this is how it works. If you're using dedicated LUNs, which you probably are if you're doing something like trying to reconstruct an existing file share in a new VM environment, you probably won't run into problems caused by the hypervisor OS. If you're not using dedicated LUNs and just adding storage pools then those LUNs will be destroyed as the HV chops them into pieces.
I haven't managed a RHEV environment in 5 years or so, and I could easily have gotten a detail or two wrong based on changes in the technology, not to mention the fragility of human memory, but I do remember how we exploited dedicated iSCSI LUNs for moving entire formatted files systems between environments. The HV will wrap the LUN in device mapper UUIDs, export it as a distinct device to the target VM, and let it sort out making sense of the data.
I don't know what VDSM tooling looks like now but, when running on RHEV, it pays to get at least a basic understanding of tying the VDSM data to the libvirt and device-mapper items/artifacts that the RHEV stack spits out. You'll learn a lot about how the tool actually works, and deepen any existing hatred towards UUIDs as the only token of identity.