Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

⁠Btrfs has been deprecated in RHEL

access.redhat.com

Post reply on HN
Print view View original

241–250 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#241

Post by [deleted] »

vbezhenar wrote: post #43
lathiat wrote: post #36

Earlier quoted context omitted.

Happy to see his Patreon is looking "healthier". I mean $1500/m isn't really that much but I'm sure last I looked it was much lower. In other news.. consider supporting the people that support you! Personally, I spent over $100/month on Patreon. Most of those are creators rather than open source people but there are a couple of open source ones such as Ondřej Surý who works on PHP packaging in Debian/Ubuntu

It's $1050, not $1500. I'm interested in two projects on Patreon (bcachefs and Matrix) and both projects are not getting nearly enough to be self-funded, so this raises the question if this model even works for Open Source. So far any advanced technology seems to be funded by some big corporation and it's not very good. But, I guess, users just don't care about good inner workings, they care about things they persona…

[deleted]

Re: ⁠Btrfs has been deprecated in RHEL

#242

Post by user5994461 »

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…

>>> This announcement from Red Hat is purely a reflection of Red Hat's engineering expertise and the way they ship kernels, and not an indictment of Btrfs itself.

It's a clear indicator that RedHat doesn't want or can't support btrfs.

Which is a reflection of btrfs AND RedHat: the effort required to maintain it, the lack of usage in RHEL paying customers, the immaturity/fast development of the filesystem.

Re: ⁠Btrfs has been deprecated in RHEL

#243

Post by e12e »

Nokinside wrote: post #176
e12e wrote: post #150

Earlier quoted context omitted.

But presumably, as copyright holders, Oracle is the entity that could try to enforce CDDL in court, in particular breaking the CDDL by mixing in GPL code in the same (ie: OS) distribution? Oracle goes: we bought Sun, and hold copyright to ZFS (also at the point of the OpenZFS fork) - RedHat could respond: we got a license - the CDDL - and Oracle could respond, sure - but CDDL isn't compatible with GPL - so you're in…

How does mixing CDDL and GPL violate CDDL? The only issue I'm aware is that mixing the two would violate GPL.

This stackoverflow question have some good points (notably, the accepted answer, and the bit about limitations - the CDDL section 6.2, for example revokes the CDDL in case of patent infringement, something that might be considered an "extra limitation" under the GPL (you're not allowed to add additional limitations to either the GPL or the CDDL). As such, the CDDL might be incompatible with the GPL up to and including v2 - while GPL3 might also be incompatible with the CDDL):

https://opensource.stackexchange.com/questions/2094/are-cddl...

https://github.com/zfsonlinux/zfs/blob/master/OPENSOLARIS.LI...

Also, the SO answer mentions consumer protection laws - but AFAIK they generally only apply to consumers - not businesses. So the GPL 0 clause might be void in many jurisdictions for individuals but still valid for businesses.

Re: ⁠Btrfs has been deprecated in RHEL

#244

Post by aeorgnoieang »

gigatexal wrote: post #228
feld wrote: post #204

Earlier quoted context omitted.

Actually it's better to just do mirrors. Avoid RAIDZ at all costs if you care about performance and the ability to resilver in a reasonable amount of time.

Sure I agree. But nested mirrors still suffer from the same issue of losing a drive and you lose everything.

> But nested mirrors still suffer from the same issue of losing a drive and you lose everything.

Are you referring to mirroring a volume or dataset on a single disk? Why would you want to do that instead of mirroring among multiple drives?

Re: ⁠Btrfs has been deprecated in RHEL

#245

Post by lunchables »

X-Istence wrote: post #63

More importantly Red Hat has deprecated FCoE in RHEL, which is big news, because at a previous $JOB they went all in on FCoE because it was supposed to be the future.

We've been big Cisco customers for years and ever since I saw FCoE I thought it was a disaster. All of the DCB extensions that had to go into ethernet to get it to work was such an ugly mess. It was just too complicated compared to alternatives, and iSCSI got a free ride on all that work (ethernet pause, flow control, etc) and was far simpler to implement. And of course with lots of 10Gb options with iSCSI offload, it was getting harder and harder to find any advantage LARGE ENOUGH in FCoE to justify it's cost and complexity.

Re: ⁠Btrfs has been deprecated in RHEL

#246

Post by lunchables »

jabl wrote: post #124
X-Istence wrote: post #63

More importantly Red Hat has deprecated FCoE in RHEL, which is big news, because at a previous $JOB they went all in on FCoE because it was supposed to be the future.

Ouch? What's the replacement then? ISCSI, or going back to FC? Or is everything cloud something these days? :)

Yeah iSCSI and NFS. Also affecting this is the huge growth in "Hyperconverged Infrastructure" (HCI).

Re: ⁠Btrfs has been deprecated in RHEL

#247

Post by mrob »

stargrazer wrote: post #151

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…

Linux 4.12 introduced dm-integrity, which adds integrity checking at the block device level, so it will work with any file system:

https://gitlab.com/cryptsetup/cryptsetup/wikis/DMIntegrity

Re: ⁠Btrfs has been deprecated in RHEL

#248

Post by sargun »

JoshTriplett wrote: post #6

Has anyone here tried bcachefs ( http://bcachefs.org/ ) for some of the same use cases as btrfs? What do people think of its current state?

I've looked into BCacheFS extensively. Two problems I have -- First, it's not there in features yet. It doesn't have quotas, nor snapshots.

Second, it lacks a formally published design for these features. Because the author is the only person with knowledge of how these things might work, it makes it really difficult to mitigate the bus factor while the project is still in heavy development.

Re: ⁠Btrfs has been deprecated in RHEL

#249

Post by thehardsphere »

lloeki wrote: post #235
thehardsphere wrote: post #210

Earlier quoted context omitted.

Taking this to its most ludicrous extreme, everyone should use Arch, and anyone who can't should... what? Not use Linux?

The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository. [0]: https://fedoraproject.org/wiki/Staying_close_to_upstream_pro...

Right, "as much as possible" implying that there are cases where this is not possible. Which is more upstream-compliant than RHEL, but not 100% "stop doing this", which is the opinion of the comment I was replying to.

Re: ⁠Btrfs has been deprecated in RHEL

#250

Post by krylon »

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…

> the "freeze the release; backport fixes" mantra.

For many customers of Red Hat, that mantra is the very reason they use RHEL in the first place.

Post reply on HN