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
2259 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.
That's an interesting proposition. Unlikely, though, considering the licensing issues which have plagued ZoL to date.
Expert
820 points
Oracle could solve the IP issue if they wanted to ... or maybe not. There's the NetApp agreement, which might be part of the IP issue. We honestly don't know.
But no way would Red Hat, or SuSE for that matter, put itself in that path. Canonical has on Ubuntu, but if you read any agreement on indemnification and coverage in Canonical Advantage, you'll find it woefully inadequate to deal with the plausible litigation should Oracle -- or even more likely NetApp -- make it an issue.
Just my personal view. I speak for no one but myself.
Red Hat
Guru
11584 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
Guru
11584 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
6688 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
6688 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
Guru
11584 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
Guru
11584 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
2259 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
21846 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
2259 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
4050 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
Guru
11584 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
21846 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
21846 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.
Red Hat
Expert
1062 points
Redhat is moving from btrfs to Stratis user level file system written in rust.
Fedora 33 supports btrfs for fedora user laptop , see cite fedora view vs Red Hat View btrfs is not for commercial enterprise / milspec work loads that tie into the Red Hat enterprise security suite , aka tpm , how-use-linux-kernels-integrity-measurement-architecture , tang clevis , tpm2 libary keylime, etc .
Red Hat has made a bet , that it will be easier to get to feature parity and beyond for Stratis Fs vs {file system x , zfs / btrfs / etc}. With a user level system file system , and produce less CVE / exploits by using RUST as that is the hope. site: Rust is our new security savior ?
As Red Hat has a whole system view of securing the OS from bad actors / hackers , in order to protect our customers / you .
Stratis fs has tooling to interop with tpm2 modules and tpm2 tooling that redhat created / supported / shipped since rhel5 .site: rh kbase:Is TPM {Trusted Platform Module} supported by Red Hat
site: RHEL 8 : managing storage file systems: chapter 21.1.8. Binding a Stratis pool to TPM
:site: upstream release notes: on clevis support as that is software layer that help manages tpm
site: upstream tpm2 next gen libary keylime watch the video on web site
site: keylime not yet merged into rhel , but in fc33
site : rhel8 Integrity Measurement Architecture + tpm2
As Stratis Fs is written in rust , it is easy to add features as not every one is a kernel hacker , and rust is starting to be used a linux kernel language site:zdnet:rust-in-the-linux-kernel:July 2021
Stratis FS has been shipping since fedora 28 Supported by Red Hat since rhel8
Here is the synopsis from See https://stratis-storage.github.io/
Stratis (which includes stratisd as well as stratis-cli), provides ZFS/Btrfs-style features by integrating layers of existing technology: Linux's devicemapper subsystem, and the XFS filesystem. stratisd manages collections of block devices, and exports a D-Bus API. Stratis-cli's stratis provides a command-line tool which itself uses the D-Bus API to communicate with stratisd.
FYI: rh kbase:Does Red Hat support the ZFS filesystem? Answer:No see kbase for why
Expert
820 points
Red Hat is traditionally 'anal' on file system adoption.
o EARLY HISTORY: REISERFS to XFS
This approach has served Red Hat and its customers well at times (e.g., ReiserFS), but also significantly delayed adoption (e.g., XFS). The Ext3 ==> Ext4 v. XFS 'history' from 2001-2009 was one I saw first-hand.
E.g., as far as I'm concerned, it should have been Ext3 + XFS and Ext4 shouldn't have existed at all. I'm sure some of the former SGI employees Red Hat hired to 'hack features' from XFS into Ext4 can comment further on that, but I'm just glad Red Hat finally decided to finally atop XFS after 2009. It became the default in 2014 for RHEL7+ after Ric Wheeler's group made the decision in late 2013.
SIDEBAR (HISTORICAL): For those interested, although the Red Hat archives from those early days are not on-line, you can read my 'summation' from 2001 on Slashdot under an old account I long abandoned.
Slashdot: RH/VA should begin looking at supporting XFS - Smith '01
More on the context of this can be found in my LinkedIn post.
LinkedIn: Looking back at SGI XFS layoffs - Smith '22
o STATE of BTRFS and BOOM/STRATIS
Ars recently had an article (2021 Sep) on the 'state' of btrfs, and it's not pretty, to put it mildly. Some of the ZFS-like features are more stable, but some ... are just downright unfinished and unstable.
Ars: Examining btrfs, Linux’s perpetually half-finished filesystem - Salter '21
Red Hat did its best in trying to push btrfs as a 'TECH PREVIEW' in RHEL6/7, but ultimately, it's been too incomplete for even 'TECH PREVIEW' in RHEL8.
I wish I could be more positive on projects like BOOM and STRATIS, I really wish. But other than BOOM's basic capability, Stratis is looking to be just another DeviceMapper facility that could just make things more confusing, kinda like integrating Multi-Disk (DM) RAID into DM-LVM2 meta-data, and even integrated XFS snapshots.
Customers are using some of these, but their understanding and proliferation is lacking. DeviceMapper (DM) is a heck of a kernel facility, but it is a bit of a support worry that the 'mapping/tooling' for a BOOM, STRATIS or other solution, might not always be in a rescue disk or something else.
o BTRFS in FEDORA, even CentOS HYPERSCALE SIG
Fedora has now adopted btrfs as it wants to move forward with some diff'ing of DNF-RPM and other, system update facilities. These overlap several Stratis and even US Federal NIST compliance requirements. I'm hopeful this will improve btrfs in the near term.
We also have the CentOS HyperScale SIG that Facebook and Twitter and others are involved with (more on that in a bit).
To start, most people are very oblivious of the history of RHEL Stream (internal), and how it's now public in CentOS Stream.
It also doesn't help that Red Hat's messaging has been awful, just like the Fedora Project nearly 2 decades ago. I tried to address this recently in my LinkedIn article.
LinkedIn: Why You Should Have Already Been on CentOS Stream Back in 2019 - Smith '20
CentOS Stream is probably the single greatest move by Red Hat since the announcement of the Fedora Project almost 2 decades ago, and will bring RHEL stability/backporting to a new series of projects.
To me, CentOS (non-Stream) never made too much sense, other than late in the lifecycle, which is what Alma/Rocky/et al. can address, when the package rate is very slow, and features aren't being added, such as where RHEL7.9 has been for the last few years. RHEL8.8 or whatever will get there too in another 2 years, when CentOS 8 Stream ends, and then Alma/Rocky/et al. can 'pick it up.'
But the promise of what the 2014 CentOS agreement should have been -- everything from long-term oVirt (RHV) to long-term Wildfly (JBoss EAP) never came to be. It was a waste of resources, when just making the internal RHEL Stream public as CentOS Stream could be far, far more fruitful. I mean, I much prefer CentOS Stream over CentOS for web servers and anything publicly facing.
Which brings us to the new HyperScale SIG.
Phoronics: CentOS Hyperscaler Is Sounding Quite Promising For The Modern Enterprise - Larabel '21
Again, this really has the backing of Facebook and Twitter and others that were already running the more internal/limited 'RHEL Stream' prior to CentOS Stream being public. Instead of having to run Fedora, one can rely on the backports/stability of CentOS Stream, but not have to wait for the full updates (e.g., RHEL8.6), getting customer hotfixes and security holes closed immediately., all while getting select, new features.
And like with Fedora, btrfs and transaction updates, are a major focus.
o ZFS IP REALITIES, hence BTRFS
ZFS is an IP landmine of NetApp as much as Oracle, and while Canonical might be willing, Red Hat and SuSE are not, and people should read the 'fine print' on 'indemnification' in their Canonical Advantage contract. In Canonical's defense, even Red Hat (let alone SuSE) limits liabilities in contracts too.
It's clear BOOM/STRATIS are not meeting the needs of Enterprises, and there are a lot of questions if they ever will. And integrating more things into DeviceMapper and XFS itself isn't going to likely be much more than a stop-gap.
The move to BTRFS is coming, so it's more about what features can be made complete over what time period. I'm encouraged but also frustrated at the same time. But it is what it is.
After all ... everyone talked about how great ReiserFS was, but it had major issues. In the end XFS 'won,' even if Ext4 ended up existing, when it shouldn't have (in my mind). It's not going to happen overnight, but clearly the Red Hat ecosystem -- between Fedora and they CentOS HyperScale SIG -- are trying to address it ASAP, even if it's still years away.
DISCLAIMER: I do not speak for any entity, and I'm not currently not employed by or even contracted to Red Hat or IBM. My views do not reflect those of any entity I am associated with, employed by or may even be an officer of. I also make no gurantees everything I have stated is accurate, other than it's been posted by me, as an individual, in 'good faith.' These views are only offered as a peer professional of some experience in watching Red Hat evolve solutions over 25 years, almost a good decade of those from the inside or a partner.