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

Linux 5.10 BTRFS performance regression

reddit.com

Post reply on HN
Print view View original

111–120 of 202 posts

Re: Linux 5.10 BTRFS performance regression

#111

Post by the8472 »

curt15 wrote: post #108
the8472 wrote: post #107

Earlier quoted context omitted.

btrfs definitely helps catching errors, even without ECC or redundancy. An example: On a server with multiple VMs on a big consumer NVMe that was starting to get unreliable Windows reported nothing other than bluescreening occasionally (sfc and chkdsk showed no errors). Linux on the other hand reported errors during a bi-weekly scrub and in the kernel logs. The SMART thresholds on the drive were strange too. A small…

>On a server with multiple VMs on a big consumer NVMe How did you avoid the crippling performance penalty with storing VM disks on btrfs? The usual workaround suggested to btrfs users is to disable copy-on-write for VM images, but doing so also turns off checksumming thus disabling the very features that make btrfs, well, btrfs.

The VMs were running on raw partitions. The btrfs reporting errors was inside a linux VM.

Re: Linux 5.10 BTRFS performance regression

#112

Post by laumars »

Volundr wrote: post #101
thomaszander wrote: post #12

Earlier quoted context omitted.

> Why does btrfs have those issues compared to other filesystems? As someone that has built infrastructure on BtrFS for years, the scary stories are mostly just hot air and the stability of other filesystems is really not significantly better. Bugs like this happen, this is why Linus releases many release-candiates every kernel, this one got through as 10 was a rather massive kernel and there were several regressions…

In my experience, the stories are real. Our entire company was offline for a day when our central storage server quit accepting writes despite having over 50% free space. That's when I learned the hard way about the data/metadata split (something I was aware of but wasn't exactly top of mind) and BTRFS balance. You can certainly say it was my fault for not reading ALL the documentation before using BTRFS, and I'd fin…

This is exactly my experience as well.

Btrfs is the C++ of file systems: it’s powerful and works for a great many people. But the tooling is intimidating to new comers and unless you know exactly what you’re doing, it’s a ticking time bomb due to the plethora of foot guns and hidden traps.

This is why some people claim to have success with it while a great many other people, rightfully, claim it’s not yet ready for prime time.

ZFS, on the other hand, has not only protected me against failing hardware but it also has sane defaults and easy to use tooling thus protecting me against my own stupidity.

Re: Linux 5.10 BTRFS performance regression

#113

Post by simion314 »

minot wrote: post #37
motakraxxer wrote: post #29

Earlier quoted context omitted.

With the problems you are listing, you would have never been able to recommend Linux. The problem stem from lack of driver support in the kernel for the devices on your machine. If that is the case, then your machine maker obviously does not support linux. So, it's no surprise that your machine had problems with linux. If you buy a machine that supports linux, you would not see those problems. Nothing to do with linu…

Sorry I failed to mention that things were much better before the update. Sure the fingerprint reader goodix never worked but the things I mentioned above are regressions. I’m all in favor of wayland but if we say we remove existing working features (fedora 32) because security or whatever we might as well wear tin foil hats and stay away from computers.

I suggest you try Ubuntu LTS (not latest) or Debian less coolness factor but you don't get regression because only security updates are happening. Your hardware must be compatible and you need to resist the urge to get the latest shiny stuff.

Re: Linux 5.10 BTRFS performance regression

#115

Post by zionic »

Volundr wrote: post #99
teekert wrote: post #91

I work with TBs of genomics data and I am at this point pretty convinced that some of that data changes on-disk. Every now and then. It's very weird. Recently I heard an interview (on one of the Jupiter broadcasting shows) about how btrfs is exposing errors of underlying hardware using their checksumming features, I had a bit of an Aha! moment. The files in question (BAM files) have a sort of checksumming built in (c…

Bit-flips are a lot more common than people think as are read errors on drives. Surprisingly, usually a bit flipping here or there doesn't cause any real problems so they tend to go unnoticed. If your working with TBs of data using a checksumming filesystem like ZFS of BTRFS would certainly be recommended, but you should ALSO make sure your using ECC RAM. Checking the integrity of the data as it comes off the disk do…

DDR5 mainstreaming ECC RAM as the default is super exciting!

Re: Linux 5.10 BTRFS performance regression

#116

Post by esgwpl »

gregkh wrote: post #56
esgwpl wrote: post #14

This version has got to be the worst kernel released in a while in terms of regression, from AMDGPU null pointer dereference crash[0] to f2fs data corruption bug[1] and now this. Fixes for these are on their way as far as I can tell but since the stable team are probably on Christmas vacation it might take a while. [0] https://bbs.archlinux.org/viewtopic.php?pid=1943906#p1943906 [1] https://bugzilla.kernel.org/show_b…

I get a vacation? Hah!

Sorry if my post sounds like a jab, it wasn't meant to be, thanks for your work and Merry Christmas.

Re: Linux 5.10 BTRFS performance regression

#118

Post by cesarb »

renewiltord wrote: post #117

Not sure why anyone would use btrfs over zfs. And that's coming from someone who used to use old XFS in an unreliable power environment.

A good reason for using btrfs over zfs is that btrfs is available by default on the Linux kernel, while zfs is only available as a third-party out-of-tree module, with all the usual problems out-of-tree modules have.

Re: Linux 5.10 BTRFS performance regression

#119

Post by therealrootuser »

simion314 wrote: post #113
minot wrote: post #37

Earlier quoted context omitted.

Sorry I failed to mention that things were much better before the update. Sure the fingerprint reader goodix never worked but the things I mentioned above are regressions. I’m all in favor of wayland but if we say we remove existing working features (fedora 32) because security or whatever we might as well wear tin foil hats and stay away from computers.

I suggest you try Ubuntu LTS (not latest) or Debian less coolness factor but you don't get regression because only security updates are happening. Your hardware must be compatible and you need to resist the urge to get the latest shiny stuff.

Over the last 15 years, I've run a lot of distros on a lot of different hardware.

On desktop, Fedora has been by far the most reliable. Ubuntu LTS, as far as I can tell from using it for work, just means that annoying bugs that have been fixed in the upstream never get backported.

Case in point: Bluetooth on Ubuntu LTS has always been much less reliable for me than on Fedora.

Disclaimer: This is only my anecdotal experience, use whatever works best for you.

Re: Linux 5.10 BTRFS performance regression

#120

Post by bashinator »

dsr_ wrote: post #105
teekert wrote: post #91

I work with TBs of genomics data and I am at this point pretty convinced that some of that data changes on-disk. Every now and then. It's very weird. Recently I heard an interview (on one of the Jupiter broadcasting shows) about how btrfs is exposing errors of underlying hardware using their checksumming features, I had a bit of an Aha! moment. The files in question (BAM files) have a sort of checksumming built in (c…

I once ran into a RAID card that would write bad data if you put it on a 90-degree PCI connector (needed for a 2U server box). No errors appeared anywhere until you encountered corrupted files.

Hardware RAID falls into the "never again" category for me.
Post reply on HN