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

281–290 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#281

Post by zerd »

mrob wrote: post #247
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

One good thing about ZFS integrity checking is that when it finds an error it can repair the bit rot from another disk if you have parity or mirroring. Can dm-integrity do that?

Re: ⁠Btrfs has been deprecated in RHEL

#282

Post by tytso »

jameskegel wrote: post #213
josefbacik wrote: post #196

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?

One of Red Hat's superpowers is in hiring relatively unknown developers, and helping them become strong participants in the open source world. But their compensation isn't super high, and when you travel on Red Hat's nickle you have to share a room with someone else --- assuming you get travel approval to go at all. For people on help organize conferences, Red Hat is rather infamous about having their full-time employees ask for travel scholarships, which originally established to support hobbyist developers.

As a result, it is not at all surprising that Red Hat ends up functioning as somewhat like a baseball farm team for companies like Facebook, Google, etc. who are willing to pay more and have more liberal travel policies than Red Hat. If someone can become a strong open source contributor while working at Red Hat, they can probably get a pay raise going somewhere else.

There is a trade off --- companies that pay you much more also tend to expect that you will add a corresponding amount of value to the company's bottom line. So you might have slightly more control over what you choose to work on at Red Hat.

Re: ⁠Btrfs has been deprecated in RHEL

#283

Post by gigatexal »

aeorgnoieang wrote: post #244
gigatexal wrote: post #228

Earlier quoted context omitted.

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?

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.

Re: ⁠Btrfs has been deprecated in RHEL

#284

Post by harshreality »

zerd wrote: post #281
mrob wrote: post #247

Earlier quoted context omitted.

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

One good thing about ZFS integrity checking is that when it finds an error it can repair the bit rot from another disk if you have parity or mirroring. Can dm-integrity do that?

Not so far, it seems. https://www.spinics.net/lists/dm-devel/msg31482.html

> this target do not provide error correction, only detection of error (such a tool could be written on top of dm-integrity though)

Re: ⁠Btrfs has been deprecated in RHEL

#285

Post by sargun »

This is disheartening to hear. We recently (Given our use-case, multi-tenant containers, there weren't many choices which had sane snapshotting support, as well as quotas and some level of subtrees. ZFS on Linux has its own share of issues. I won't say that Btrfs was without issues -- there is still a lot of performance work that needs to be done, especially in a multi-tenant workload, but it looked like there were solutions available.

XFS is an excellent filesystem, and it may work well for our usecase in the near future. It's exciting to see new XFS features landing, like reflinks, and collapsing ranges. Hopefully, folks like Redhat continue trying to bring XFS to the future.

Re: ⁠Btrfs has been deprecated in RHEL

#286

Post by lomnakkus »

buster wrote: post #153
lomnakkus wrote: post #123

Earlier quoted context omitted.

> "Need" as in "will you use it?". Well, many of us have experienced a botched system package upgrade or two. If the file system supports snapshots, then the package manager could automatically ensure fully atomic package upgrades. That should be reason enough, I should think. Re: The data loss issue: Yes, I've actually have XFS completely throw away a file system upon a hard power-off + boot-up cycle. (This was ages…

Good point. I'm using Debian as my Desktop for many years. I don't remember a "botched" system package upgrade in the last 5 years, but i've probably learned over years how to handle dpkg/apt. The atomic updating is a very interesting topic and the reason why i find ostree/guix/nixos very appealing. Note that neither ostree nor guix or nixos make use of filesystem snapshots, afaik. OSTree even documents why it won't…

> So, it's a definitely a nice-to-have, but not something i need, because i can handle dpkg/apt much better then i could handle filesystem internals.

I don't think you're seeing my point. You wouldn't have do anything -- it would all be done automatically as long as your file system supports snapshots.

BTW, to your "I know how to use dpkg/apt": It's not about knowledge. I could well be said to be at an "advanced" level of expertise in system maintenance, but "system upgrade" fuckups had nothing to do with me, but everything to with bad packaging and/or weird circumstances such as a dist-upgrade failing midway through because some idiot cut a cable somewhere in my neighborhood.

While Nix and the like are nice and all, they're currently suffering from a distinct lack of manpower relative to the major distributions. They also don't quite fully solve the "atomic update" problem, but that's a tangent. Then, OTOH, some of them have other advantages such as the easy of maintaining your full system config in e.g. Git. Swings and roundabouts on that front. FS support for snapshots would help everybody.

Re: ⁠Btrfs has been deprecated in RHEL

#287

Post by fundabulousrIII »

josefbacik wrote: post #272
pgaddict wrote: post #255

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…

All this talk about Oracle is just plain stupid. Oracle doesn't control anything, the community does. One core developer still works on Btrfs from Oracle, the vast majority of the contributions come from outside Oracle. Now as to > "Why Red Hat does not have engineers to support btrfs?" You have to understand how most kernel teams work across all companies. Kernel engineers work on what they want to work on, and comp…

Wholeheartedly agree that btrfs isn't ready for a real customer base. I wish SuSE would have learned that lesson before they pushed it as default.

Re: ⁠Btrfs has been deprecated in RHEL

#288

Post by X-Istence »

KaiserPro wrote: post #121
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.

FCoE died a death Expensive hardware, with little gain sadly. It was a nice idea, however at its very core is a fairly large problem: converged network adaptors are problematic. Unless you have lots of bandwidth in said adaptor (ie 56gig inifiband) you are going to get contention between network and disk IO.

I agree, not only that, but at least with Cisco gear FCoE was a real pain in the behind to manage and configure. So much duplication in configuration and settings across a lot of gear, and it never was as smooth as they made it out to be.

Re: ⁠Btrfs has been deprecated in RHEL

#289

Post by crudbug »

chasil wrote: post #261
pgaddict wrote: post #255

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 uses RHEL for their Unbreakable Linux [0] distribution. The least thing they can do is open up ZFS for the Linux community.

[0] - https://linux.oracle.com/

Re: ⁠Btrfs has been deprecated in RHEL

#290

Post by cmurf »

gcp wrote: post #73
cmurf wrote: post #66

Unsurprising. Red Hat has not hired upstream Btrfs developers for years, where SUSE has hired bunches. Meanwhile Red Hat has upstream ext4, XFS and LVM developers. If you're going to support a code base for ~10 years, you're going to need upstream people to support it. And realistically Red Hat's comfortable putting their eggs all in the device-mapper, LVM, and XFS basket. But, there's more: https://github.com/strati…

As for the significant technical issues, one thing is the core decision to make it a CoW system, which has fundamental performance issues with many workloads that are exactly those used in the server space. You can disable CoW, but you lose many reasons to use btrfs in the first place if you do. When I gave up on it there were also fundamental issues with metadata vs data balancing, not-really-working RAID support, a…

Unconvincing. LVM's snapshots are CoW whether thick or thinly provisioned. And while not yet merged in mainline, XFS devs are working on CoW as well which is used when modifying reflinked files (shared extents).

Btrfs behaves basically like that with 'nodatacow' today. It will overwrite extents if there's no reflink/snapshot. If there is, CoW happens for new writes and any subsequent modifications are overwrites until there's a reflink/snapshot in which case CoW happens.

The 'nodatacow' flag can be used as either a mount option, or selectively with an xattr per subvolume, directory, or file. And in all cases, metadata writes (the file system itself) are still CoW.

Post reply on HN