Live data from Hacker News

⁠Btrfs has been deprecated in RHEL

access.redhat.com

261–270 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#261

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 muc…

I think a natural follow-up question is "Why Red Hat does not have engineers to support btrfs?" That is, if the lack of engineers is a symptom, what is the cause? I'm pretty sure, had RH wanted they could either hire or assign engineers to maintain the btrfs code, take care of patches from upstream, etc. So why didn't that happen? I wonder what is your opinion on that. I see a bunch of possibilities (not necessarily…

Oracle has essential control of both "nextgen" filesystems that should be used in Linux - as Sun, they developed and licensed ZFS, and they are the chief contributors of BtrFS. Their refusal to release ZFS under a license that is compatible with the GPL is keeping it out of Red Hat's distribution.

This move by Red Hat must be seen as a provocation of Oracle, to force either greater cooperation and compliance in producing a stable BtrFS for RHEL, or the release of ZFS under a compatible license. Red Hat has put an end to BtrFS for now, and Oracle will have to go to greater lengths to use it in their clone. Customers also will not want it if it does not run equally well between RHEL and Oracle Linux.

It is obvious that Oracle will have to assume higher costs and support if they want BtrFS in RHEL. Red Hat is certainly justified in bringing Oracle to heel.

Oracle recently committed preliminary dedup support for XFS, so they must be intimately aware of the technical and legal issues behind Red Hat's move.

https://blogs.oracle.com/linuxkernel/upcoming-xfs-work-in-li...

Re: ⁠Btrfs has been deprecated in RHEL

#262
post #3

Deprecated? In favour of what? Will Redhat too (like Ubuntu) start shipping ZFS?

Red Hat will never ship ZFS, because its an entity that exists in the US and a probable target for lawsuits / license violation if ZFS is included.

What's the risk involved for Red Hat in shipping ZFS? OpenZFS and ZFS-on-Linux are under the CDDL, a legitimate open-source license that some feel may be GPL-incompatible. Red Hat distributes non-GPL programs as a matter of routine, and I'm sure this includes other CDDL programs, especially considering Red Hat's enthusiastic involvement in the Java ecosystem.

The only potential risk is that the GPL is so virulently infectious that any driver is automatically GPL'd by virtue of its own existence as a compiled kernel module, but that possibility seems fairly remote, and it hasn't seemed to affect the distribution of other purportedly-non-GPL kernel modules.

I'm not a lawyer so maybe I'm missing something.

Re: ⁠Btrfs has been deprecated in RHEL

#263
post #194

Earlier quoted context omitted.

Thanks. Any indication why RH didn't hire btrfs devs? It looks like a decision was made that it wasn't strategic (obviously xfs on Linux has a much longer history).

They brought on Zach right before I left specifically to help with the effort, but he left as well. I can't really speak to Red Hat's overall strategic decisions, but really they have a large local file system team, and a lot of them are xfs developers. You aren't going to convince Dave Chinner he should go work on Btrfs instead of XFS. Unless there's somebody internally that actually wants to work on Btrfs the work…

XFS does not support transparent compression, error detection and recovery, and (as yet) deduplication.

Fragmentation is also an issue, and xfs_fsr should be run at regular intervals to "defrag" an XFS file system. (I assume that) BtrFS handles this more intelligently.

I'd love to see XFS get some or all of these features.

Re: ⁠Btrfs has been deprecated in RHEL

#264
post #202

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 muc…

The problem is that Redhat and others are refusing to challenge the norm and break away from the "freeze the release; backport fixes" mantra. Stop backporting fixes. You're forking the codebase. Ship exactly what upstream provides. Teach upstream projects how to do better release engineering if they're abandoning major releases to early or breaking API/ABI in a minor release. Stop backporting fixes. You're forking th…

We use both RHEL and Oracle Linux as a peer to VAX VMS and Unisys(Univac) OS2200 (a COBOL mainframe).

From the perspective of legacy systems, Red Hat's approach is more comfortable.

Re: ⁠Btrfs has been deprecated in RHEL

#265

Considering the size of disks now-a-days, the chance of bit rot is high. And (I don't have the original source) on SSD, bit rots probability is higher still. So... ZFS and BTRF have meta-data as well as data checksumming. From what I've read, XFS may have metadata checksumming, but not on the data side of things. I consider checksumming important. Do others? What is the solution? What other file systems offer that so…

Development focus is switching to LXD.

Re: ⁠Btrfs has been deprecated in RHEL

#266
post #205

Earlier quoted context omitted.

I have one machine running XFS but if that one is representative then I won't be installing XFS anywhere else and would happily discourage others from using it. It is terribly slow when doing some fairly common operations when you have a large number of small files.

You have to tune the parameters at filesystem creation time if you care about small file performance. It was designed for large files.

What parameters? This guide[1] only mentions two things in relation to number of files. The first is inode count, for which performance is binary. The other is files in a single directory, and it says that the default setting is fine for a million. There's no explanation for the performance jacquesm describes.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

Re: ⁠Btrfs has been deprecated in RHEL

#267
post #62
post #52

Earlier quoted context omitted.

Worse, I browse without javascript and their page has no text. It's utterly terribly designed to be an open source information page.

Even as paying customer I wouldn't want to put up with that shit.

You mean ESPECIALLY as a paying customer! You paid for the right to bitch, and you should.

Re: ⁠Btrfs has been deprecated in RHEL

#268
post #261

Earlier quoted context omitted.

I think a natural follow-up question is "Why Red Hat does not have engineers to support btrfs?" That is, if the lack of engineers is a symptom, what is the cause? I'm pretty sure, had RH wanted they could either hire or assign engineers to maintain the btrfs code, take care of patches from upstream, etc. So why didn't that happen? I wonder what is your opinion on that. I see a bunch of possibilities (not necessarily…

Oracle has essential control of both "nextgen" filesystems that should be used in Linux - as Sun, they developed and licensed ZFS, and they are the chief contributors of BtrFS. Their refusal to release ZFS under a license that is compatible with the GPL is keeping it out of Red Hat's distribution. This move by Red Hat must be seen as a provocation of Oracle, to force either greater cooperation and compliance in produ…

Oracle is not the "chief contributors" of Btrfs. If anyone is, it's Facebook. Chris Mason (the btrfs creator) worked for Oracle. He left in 2012.

> This move by Red Hat must be seen as a provocation of Oracle

I doubt it.

Re: ⁠Btrfs has been deprecated in RHEL

#269
post #110

Earlier quoted context omitted.

… for which Oracle owns the copyright.

I can't see that the copyright matter here. What matters is the license. Oracle can't unlicence what Sun code is already part of OpenZFS.

Oracle can relicense their codebase anytime they want. They _cannot_ be constrained by OpenZFS/Illumos unless they accept patches from them without copyright assignment.

Re: ⁠Btrfs has been deprecated in RHEL

#270

Earlier quoted context omitted.

They brought on Zach right before I left specifically to help with the effort, but he left as well. I can't really speak to Red Hat's overall strategic decisions, but really they have a large local file system team, and a lot of them are xfs developers. You aren't going to convince Dave Chinner he should go work on Btrfs instead of XFS. Unless there's somebody internally that actually wants to work on Btrfs the work…

I'm feeling a subtext here that maybe RH isn't a desired place to work, when I've always imagined the opposite. Is this the case?

I think there are some ways that RH would be less desirable for many people than a BigCo. When I was interested in working for them they had offices in inconvenient locations and a requirement that you (or at least, I) work in one of them -- e.g. their "Boston" office is 30 miles away in Westford, and their headquarters are in North Carolina. That's disqualifying for many people.

I imagine they pay significantly less than the other companies (e.g. Facebook) who want to hire Btrfs devs can afford to, too.

Post reply on HN