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

311–320 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#311

Post by vbezhenar »

tylerjd wrote: post #299
vbezhenar wrote: post #48

I don't think this matters much. If you want btrfs, you'll likely be able to get kernel module from EPEL even if they'll stop shipping it. It's like deprecated and unsupported LXC which could be used just fine and which doesn't have usable replacements.

> deprecated and unsupported LXC Where did you hear this? This is news to me. https://linuxcontainers.org/ and https://github.com/lxc/lxc both seem active and supported by Canonical to me. The only deprecated project by them is listed to be CGManager.

LXC is unsupported by RHEL. They chosen Docker as a primary container solution. LXC as project is fine, of course.

Re: ⁠Btrfs has been deprecated in RHEL

#312

Post by belorn »

cryptonector wrote: post #276
belorn wrote: post #251

Earlier quoted context omitted.

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

CDDL is per-file.

How does this change this?

I take a CDDL licensed source code file. I take a GPL licensed source code file. I add inline the GPL licensed code to the CDDL licensed file, and release an executable form of the result. In order to comply with the GPL I then give out a single source code file under the GPL license terms with the code from the two files.

Is this in compliance with the CDDL terms and conditions?

Re: ⁠Btrfs has been deprecated in RHEL

#313

Post by cryptonector »

gcp wrote: post #185
pgaddict wrote: post #107

Earlier quoted context omitted.

I find the suggestion that the technical issues are caused by the CoW design a bit strange. Sure, making the filesystem CoW-based means there are some inherent costs, but it allows the filesystem to implement some interesting features (e.g. snapshots) in a more efficient way. For example if you want to do snapshots with ext4/xfs, you'll probably do that using LVM (which you can see as turning the stack into a CoW). I…

> it allows the filesystem to implement some interesting features (e.g. snapshots) in a more efficient way. Interesting features are worthless when reading and writing data is prohibitively slow. Or when there are documented cases where updating a file in random-access manner can cause its storage requirement to balloon to blocks^2.

There's a write magnification effect when using CoW. The ZIL helps with this because the ZIL itself is not CoW'ed, and it allows deferring writes, which allows more transactions to share interior metadata blocks, thus reducing the write magnification multiplier. I don't get where you get O(N^2) from.

As to snapshots, who cares, they cost nothing to create and they do not slow down writes -- they only slow down things like zfs send (linearly) and they cost storage over time, but not much more.

Re: ⁠Btrfs has been deprecated in RHEL

#314

Post by digi_owl »

cyphar wrote: post #224
feld wrote: post #202

Earlier quoted context omitted.

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 get the feeling you've never had to provide support for a distribution before. There are many guarantees that Red Hat or SUSE provide that are not provided by upstream projects. Freezing the release is the only sane way of doing it, and backporting fixes is necessary. There are exceptions to this, such as stable kernels (which was started by GregKH out of frustration of the backporting problem while at SUSE). Upstr…

Sadly more and more upstream wants to have their cake and eat it to. Just look at Flatpak, that is all about moving the updating and distribution from distros to upstream.

Re: ⁠Btrfs has been deprecated in RHEL

#315

Post by digi_owl »

krylon wrote: post #250
feld wrote: post #202

Earlier quoted context omitted.

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.

Indeed. Or they would have stuck to using Windows, or some commercial Unix.

Sadly i feel that more and more upstream wants it both ways, be able to push their latest and shiniest, and keep ignoring any need for interface stability etc.

Frankly i suspect the end result of the likes of Flatpak will be that upstream push whole distros worth of bundled libs, just so they don't have to consider interface stability as they pound out their shinies in their best "move fast and break things" manner.

Re: ⁠Btrfs has been deprecated in RHEL

#316

Post by [deleted] »

krylon wrote: post #250
feld wrote: post #202

Earlier quoted context omitted.

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.

[deleted]

Re: ⁠Btrfs has been deprecated in RHEL

#317

Post by cryptonector »

tylerjd wrote: post #304
rleigh wrote: post #295

Earlier quoted context omitted.

It's certainly interesting, but if you look at the ZFS design they were inspired by, they got a lot wrong. Some points to consider: With ZFS, you have a hierarchy of datasets. These inherit properties from their parents, and while the mountpoints can also mimic this hierarchy, the mountpoint property can be set independently. Btrfs couples the two concepts, forcing subvolumes to be in a specific place in the actual f…

Are you trying to say that BTRFS is supposed to compete feature-to-feature with ZFS? It's not. https://lwn.net/Articles/342892/ >I had a unique opportunity to take a detailed look at the features missing from Linux, and felt that Btrfs was the best way to solve them. >From other points of view, they are wildly different: file system architecture, development model, maturity, license, and host operating system, among…

Yes, that's what rleigh is saying. It's what I'm saying.

ZFS sets a very very high bar indeed. There are things that could be done better (I've talked about some of those on HN). But pound for pound, it's the best storage stack today and has been for over a decade. ZFS is the benchmark against which all others are to be stacked. There will be applications for which you will find a more performant solution, maybe, but altogether, ZFS has been the last word in filesystems for a long time now.

The most interesting competition, IMO, is from HAMMER. We'll see how that progresses.

Re: ⁠Btrfs has been deprecated in RHEL

#318

Post by cryptonector »

cookiecaper wrote: post #262
silly-silly wrote: post #215

Earlier quoted context omitted.

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

The risk is FUDdy, but not entirely imaginary. In particular there's the thread of a threat of patent lawsuits from a variety of players in the industry. Of course, that's always the case in this industry, so I don't buy it. But RH might, and that's their call.

My guess too is that if Canonical manages to go a few years without a lawsuit from kernel copyright holders then we might see more of what it is doing. But RH would -I guess!- still suffer from patent FUD and so stay away from ZFS.

That's all fine by me. The better for RH's competition. More competition, mo' betta.

Re: ⁠Btrfs has been deprecated in RHEL

#319

Post by gigatexal »

aeorgnoieang wrote: post #310
gigatexal wrote: post #283

Earlier quoted context omitted.

how would you set up a large pool? two sets of say 5 disks in a mirror raidz1 would still fail if a disk in one set failed and a disk in the other set failed. I guess you could do a stripe setup of 5 sets of 2 disks in mirrors. Still it seems wicked risky to me. I do agree though mirroring has been the best for speed but a lot of that changes with nicer SSDs especially NVMe ones.

A Reddit post about that blog post in my other reply: - [You should use mirror vdevs, not RAIDZ. : DataHoarder]( https://www.reddit.com/r/DataHoarder/comments/2v0quc/you_sho... )

I wonder if resilvering is still an issue with SSDs. But I cede your point, nested vdevs of two disks making mirrors makes sense. It doesn't sit well still, but makes sense

Re: ⁠Btrfs has been deprecated in RHEL

#320

Post by nailer »

cjbprime wrote: post #270
jameskegel wrote: post #213

Earlier quoted context omitted.

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…

Isn't FBs internal distro Fedora based? I wonder if FB has a solid RH-based btrfs production ready kernel floating about.
Post reply on HN