⁠Btrfs has been deprecated in RHEL • Hacker News Board

Re: ⁠Btrfs has been deprecated in RHEL

#251

Post by belorn » Wed, Aug 02, 2017, 3:47 PM UTC

Nokinside wrote: post #227

belorn wrote: post #219

Earlier quoted context omitted.

CDDL says: Source code must be licensed under CDDL. GPL says: Source code must be licensed under GPL. If you follow the conditions of GPL, you are violating the condition of the CDDL. If you are following the conditions of CDDL, you are violating the GPL. Basic binary logic. To add: "the engineers who had written the Solaris kernel requested that the license of OpenSolaris be GPL-incompatible" . A license is really j…

Neither license forbids mixing with other licenses. As long as the demands of both are met, they can apply to the same source code. >If you are following the conditions of CDDL, you are violating the GPL. Basic binary logic. Relationship between licenses can be transitive but not commutative. As far as I know CDDL allows using with code under GPL but GPL does not allow using code under CDDL. CDDL copyright owners hav…

If CDDL has no issue with GPL conditions, then follow the GPL and everything is fine.

CDDL has this text: "Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License"

So you take some CDDL code, and some GPL code, and you put that whole new source code tree under GPL in order to fullfill the GPL license condition. Are you then in compliance with the CDDL code? My concussion is that you are not, as that would be in conflict with the above condition of the CDDL. The source code tree would not be "distributed only under the terms of this license".

Re: ⁠Btrfs has been deprecated in RHEL

#252

Post by Torgo » Wed, Aug 02, 2017, 3:52 PM UTC

jorrizza wrote: post #182

Strange decision, as systemd-nspawn[1] specifically mentions and supports btrfs as a CoW filesystem for its containers. And as far as I understand, systemd is primarily developed by Red Hat employees. So either they'll add support for CoW alternatives, or they'll remove btrfs support from systemd-nspawn all together. [1]: https://www.freedesktop.org/software/systemd/man/systemd-nsp...

nspawn uses btrfs snapshotting natively for its templating and no other FS (ZFS was explicitly rejected by Mr. Poettering because "it's not in the kernel") so yeah either they are going to have to do something about this or there will be a significant step down in functionality for nspawn. I can't see how this isn't really bad news for nspawn.

I guess one option is to pull btrfs tree into Systemd :-)

Re: ⁠Btrfs has been deprecated in RHEL

#253

Post by mhd » Wed, Aug 02, 2017, 3:53 PM UTC

Is JFS still a thing in the Linux world? I remember using it for some partitions not because it was particularly high performant, but because it was supposed to have very few worst case scenarios…

Re: ⁠Btrfs has been deprecated in RHEL

#254

Post by fl0wenol » Wed, Aug 02, 2017, 3:58 PM UTC

fleetfox wrote: post #155

fulafel wrote: post #30

Earlier quoted context omitted.

The E stands for "Enterprise", so there's a hint about the target audience. You can get support for a 10 year old RHEL version after you entangle it to your stuck in time IT infra :)

It seems like "Enterprise" is synonym with "Technical debt"

More accurately, it's a synonym for "Allows my line-critical COTS to run predictably"

If you're not in a tech business, and are therefore using other people's software, then you want to be on the same platform that they were during development which would have been years ago. If it's Linux, then it's something like RHEL.

Re: ⁠Btrfs has been deprecated in RHEL

#255

Post by pgaddict » Wed, Aug 02, 2017, 4:01 PM UTC

josefbacik wrote: post #183

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 independent ones):

1) Politics. Perhaps RH wants to kill btrfs for some reason?

I see this as rather unlikely, as RH does not have a competing solution (unlike in the Jigsaw controversy, where they have incentives to kill it in favor of the JBoss module system).

2) Inability to hire enough engineers familiar with btrfs, or assign existing engineers.

Perhaps the number of engineers would be too high, increasing costs. Especially if not only to maintain the RHEL kernels, but to contribute to btrfs and move it forward.

Or maybe there's a pushback from the current filesystems team, where most people are xfs developers?

3) Incompatible development models.

If each release requires a rebase, perhaps supporting btrfs would require too much work / too many engineers, increasing costs? I wonder what Suse and others are doing differently, except for having in-house btrfs developers.

4) Lack of trust btrfs will get mature enough for RHEL soon.

It may work for certain deployments, but for RHEL customers that may not be sufficient. That probably requires a filesystem performing well for a wider range of workloads.

5) Lack of interest from paying RHEL customers.

Many of our customers have RHEL systems (or CentOS / Scientific Linux), and I don't remember a single one of them using btrfs or planning to do so. We only deal with database servers, which is a very narrow segment of the market, and fairly conservative one when it comes to filesystems.

But overall, if customers are not interested in a feature, it's merely a pragmatic business decision not to spend money on it.

6) Better alternatives available.

I'm not aware of one, although "ZFS on Linux" is getting much better.

So I tend to see this as a pragmatic business decision, based on customer interest in btrfs on RHEL vs. costs of supporting it.

Re: ⁠Btrfs has been deprecated in RHEL

#256

Post by cookiecaper » Wed, Aug 02, 2017, 4:06 PM UTC

bedros wrote: post #38

I think this is a political move disguised as technical move oracle pays the developers of btrfs [0] redhat hates the guts of oracle, since oracle released oracle linux, which is a clone of redhat enterprise (based on centos) so, redhat wants to cripple btrfs and hurt oracle. However, btrfs is my favorite FS, been using it on my home computer and backup drives for at least 6 years, before it was included in the kerne…

If anything, the political move would've been Oracle's sponsorship of btrfs in the first place. They want to push people to enterprise OS/storage systems, so they've told everyone "Oh yeah, btrfs is coming soon, it'll be great" ... and it isn't great. It sucks.

I've finally broken and installed ZOL (ZFS on Linux) after trying btrfs repeatedly over the last three years. ZFS is already a breath of fresh air and I've only been using it a couple of months. For whatever reason, btrfs came together as a messy hodge-podge, and it shows in bad performance for many use cases (e.g. "omg I forgot nodatacow"), buggy implementations, difficult user interfaces, kernel bugs, etc.

btrfs needs a reboot (I hear bcache? is trying). Meanwhile, everyone should stop getting hung up on the arcane licensing details and just use ZFS directly. It can't be distributed as part of the kernel, but that's why we have distributions, isn't it? They bundle all that crap together for us. There shouldn't even be the normal OSS infighting because this isn't a proprietary blob or something, it's just using a license that's GPL-incompatible.

The best thing Linus could do for the community at large would be to fork and start committing to ZOL, giving it a tacit endorsement.

Re: ⁠Btrfs has been deprecated in RHEL

#257

Post by noselasd » Wed, Aug 02, 2017, 4:06 PM UTC

feld wrote: post #202

josefbacik wrote: post #183

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…

I for one am very grateful Red Hat does not do that. We have a kernel driver for custom hardware, there's around 80 of these devices in the world, split roughly 50/50 between Windows and Red Hat users. While these devices are not cheap, we could not recoup the cost of maintaining it if we had to track the upstream kernel all the time - we tried, and could not justify the cost.

The number of times the APIs changes from under your feet is astounding - even with just keeping up with Red Hat, we spend around 4-6 times the engineering time on the driver compared to what we do with the Windows version of the driver, tracking upstream gave us almost an order of magnitude more work (And keep in mind that /only/ supporting the most recent upstream kernel is rarely an option - several versions need to be supported concurrently)

Re: ⁠Btrfs has been deprecated in RHEL

#258

Post by cookiecaper » Wed, Aug 02, 2017, 4:10 PM UTC

RX14 wrote: post #165

I've done many bad things to BTRFS, used it on multiple drives of differing sises, used it on drives connected over the cheapest USB to SATA adapters I could find, used it on disks with consistent corruption for over a year, and it's handled it gracefully. I've also been using btrfs as the backend to docker for a long time on my desktop PC and never noticed any problems. BTRFS has been rock solid for me. I don't doub…

btrfs requires far too much maintenance to be a good general-purpose FS, and it absolutely crumbles under certain not-too-uncommon use cases (specifically, databases and VMs). I really wanted to like btrfs and used it extensively over the last couple of years, but I've finally given up and moved on to ZFS, and I'm grateful that I did. Give it a try.

Re: ⁠Btrfs has been deprecated in RHEL

#259

Post by gkya » Wed, Aug 02, 2017, 4:16 PM UTC

feld wrote: post #202

josefbacik wrote: post #183

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…

You cant teach anything to anybody. An unrelated proof: I'm having to write a bot with phantomjs to scrape my uni's announcements page and turn it into an RSS feed so that I won't have to periodically control it; because they decided wordpress wouldnt cut it and they needed some blumming angular.js stuff, breaking all the urls and removing any sort of rss feeds on the way. And all it is is a blog, basically, nothing more. Mailed them telling that I used to use that stuff, no replies in weeks. At least I'm learning phantomjs which seems to be very useful of a tool.

Re: ⁠Btrfs has been deprecated in RHEL

#260

Post by __david__ » Wed, Aug 02, 2017, 4:17 PM UTC

justin66 wrote: post #24

I am as happy as anyone that XFS is finally getting the position of honor it deserves on enterprise Linux (something like 15 years later than it should have, grumble grumble) but it doesn't really take the place of what btrfs was trying to do. Only ZFS is in a position to do that. I wonder if there are any plans for supporting the native port on RHEL.

Anecdote time: Last month I had an XFS volume fail on me. It got some sort of internal inconsistency and refused to work (all fs calls returned errors until I unmounted). This is where I discovered that XFS still has extremely poor recovery tools.

xfs_repair will complain if there is a journal present and tell you to mount the fs to replay the journal. But mount would refuse, saying the fs was inconsistent. So the only option was to xfs_repair -L to just throw out the journal.

Then, xfs_repair sucked up something like 30GB or more of RAM, so I had to make a huge swapfile so that the kernel would OOM the repair.

Then, after roughly 20 to 30 hours of repair it would exit with an error. At that point it would actually mount, but hitting certain areas of the filesystem would trigger the inconsistency again and start the entire process over.

In the end I couldn't fix it and sadly had to reformat. I chose ext4 when I did—I've had lots of experience with ext3 and 4 and I've never had a filesystem that I couldn't at least make consistent again (even if it loses some data).