Live data from Hacker News

⁠Btrfs has been deprecated in RHEL

access.redhat.com

101–110 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#101
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…

> I think this is a political move disguised as technical move

You literally have no idea what you're talking about, and I doubt you've used btrfs seriously, or you wouldn't talk this shit. The fact it's been upvoted so heavily just shows what absolute technically-false nonsense will draw support at HN.

Re: ⁠Btrfs has been deprecated in RHEL

#102
post #95

I tried btrfs and got bitten by bugs; not doing that again. Judging from this move by RH, it looks like I wasn't the only one.

What bugs? I recently setup a software mirroring raid with btrfs and I'm loving features like checksumming. It makes me feel my data is quite safe and can't bit rot anymore. So far it is working fine.

[deleted]

Re: ⁠Btrfs has been deprecated in RHEL

#103

I have used Btrfs in production and I would say it's great. It's super easy to just add an extra EBS volume and attach to a Btrfs volume and now you have more disk space. Performance is good enough for me as well, I used it as storage for InfluxDB and Docker. Luckily this is only Redhat, not Btrfs itself.

How much did you deal with snapshots? Because I've had crippling performance problems stemming from them. Even something as simple as having 90 daily snapshots and deleting the oldest few can cause trouble, where the filesystem does not respond to any requests for multiple seconds. And that's on an SSD. I don't remember if it was deleting snapshots or running balance, but I've had Btrfs on a hard drive not respond to I/O requests for two minutes. A light-use server that had snapper running for a few months fragmented so badly that it regularly hitched up even after snapshots were paused. I had to migrate the entire filesystem.

I'm still using Btrfs on my backup system, but that's only because I like the dedup enough to overlook the brief hangs.

Re: ⁠Btrfs has been deprecated in RHEL

#104
post #95

Earlier quoted context omitted.

What bugs? I recently setup a software mirroring raid with btrfs and I'm loving features like checksumming. It makes me feel my data is quite safe and can't bit rot anymore. So far it is working fine.

Hi. Did you notice that the official description of RAID-1 is "Mostly working"? Are you aware if one of your drive fails, you have one chance to re-mirror it, before the remaining drive can no longer be mounted read-write and you need to dump the filesystem and re-create from scratch?

RAID1 meaning you get one chance. Just move to RAID10 if you're worried. (/s)

Re: ⁠Btrfs has been deprecated in RHEL

#106

Well I used btrfs as a root filesystem for quite a while, until I realized it was pig slow for sync() -- I mean, it would take AGES to do and apt-get upgrade for example. I ended up having to do some tasks using 'eatmydata' [0] to make it all better, risking filesystem corruption in trade for speed. Also, at the time, there was no functioning fsck. So I moved back safely to ext4 and never looked back! [0]: https://ww…

We are using XFS for most of our production workloads, it turned out to be an excellent choice for most data heavy use cases. Brtfs was never an option, it is a bad idea to gamble with beta technology for data storage that a production system relies on. ext4 vs xfs is a much interesting argument, I haven't had time to follow up on this.

Re: ⁠Btrfs has been deprecated in RHEL

#107
post #73
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…

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). In my experience the performance impact of creating a snapshot on ext4/LVM is about 50%, so you cut the performance in half. While on ZFS the impact is mostly negligible, due to the filesystem is designed as CoW in the first place.

And thanks to ZFS we know that it's possible to implement a CoW filesystem that provides extremely stable and balanced performance. I've done a number of database-related tests (which is the workload that I do care about) and it did ~70-80% TPS compared to ext4/xfs (without snapshots). And once you create a snapshot on ext4/xfs, the performance tanks, while ZFS works just like before, thanks to the CoW design.

Unfortunately, BTRFS so far hasn't reached this level of maturity and stable performance (at least not in the workloads that I personally care about). But that has nothing to do with the filesystem being CoW, except perhaps that CoW maybe makes the design more complicated.

Re: ⁠Btrfs has been deprecated in RHEL

#108
post #97
post #86

Earlier quoted context omitted.

You're joking, surely. XFS has outperformed EXT4 in almost all "high" use-cases in my experience and testing: Large files (500GB~) or many small files (128k files * 2,400,000 or so). EXT4 under those loads is comically bad. BTRFS is also terrible at this, only XFS and ZFS are good at handling it.

On the other hand on database workloads, for example PostgreSQL, XFS and EXT4 are about equal these days. ZFS (at least on Linux) and Btrfs are both clearly slower on those workloads. Here is one benchmark, but I have seen plenty of similar benchmark results for PostgreSQL showing the same thing: https://blog.pgaddict.com/posts/postgresql-performance-on-ex...

I don't mean to be so blunt, but, no shit.

XFS's target is for big files, or tiny files over huge volumes.

PostgreSQL splits tables over 1G files, which is ideal for EXT4.

Re: ⁠Btrfs has been deprecated in RHEL

#109
post #94

Well I used btrfs as a root filesystem for quite a while, until I realized it was pig slow for sync() -- I mean, it would take AGES to do and apt-get upgrade for example. I ended up having to do some tasks using 'eatmydata' [0] to make it all better, risking filesystem corruption in trade for speed. Also, at the time, there was no functioning fsck. So I moved back safely to ext4 and never looked back! [0]: https://ww…

Over the recent years on every new laptop install i switched between filesystems, so i had ext3/4, btrfs and (currently) xfs on my system. I have to say, btrfs had the most glitches (a few years back), although it worked ok'ish (no data loss). Nowadays, i must say that i very much prefer a stable filesystem with as little complicated logic as possible. I actually never use snapshots or subtrees! I never put another d…

> Will you really need and use subtrees/snapshots/XYZ on your system?

It's a valid question, but not the best one. Almost nobody needs snapshots. But they make things easier. You most likely don't need a journaled fs in your laptop either (battery level notification should take care of the issues). But it does make life better.

"Need" is not the threshold I'm interested in. Most features, I'd like. One feature I think I do need most is scrubbing, which is still absent from most filesystems :(

Re: ⁠Btrfs has been deprecated in RHEL

#110

Earlier quoted context omitted.

Redhat hasn't been on the best of terms with Oracle, so I suspect that they want to stay clear of ZFS. It does however leave Redhat without a more modern feature rich filesystem. Perhaps Redhat could help to develop snapshots on XFS. It's not the only feature XFS is missing, but it's a start.

>Redhat hasn't been on the best of terms with Oracle, so I suspect that they want to stay clear of ZFS The only connection Oracle has to ZFS on Linux is ownership of some patents that the license allows you to use, their reluctance is based on distribution issues between the GPL and CDDL.

… for which Oracle owns the copyright.
Post reply on HN