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

41–50 of 202 posts

Re: Linux 5.10 BTRFS performance regression

#41

Post by throwii »

jeromenerf wrote: post #20
throwii wrote: post #6

Earlier quoted context omitted.

Why does btrfs have those issues compared to other filesystems? I'd love to use btrfs too. Note that I deeply respect people who can write such complicated code, which I couldn't. Would Rust solve the non-speed issues? Rust-in-kernel discussion from August: https://lwn.net/Articles/829858/

> Why does btrfs have those issues compared to other filesystems? Mostly because it has lots of features and as a consequence, is pretty large and complex. Closer to ZFS than ext2. Btrfs suffers from a initial bad rep, which is difficult to overcome.

Good theory, thank you.

Re: Linux 5.10 BTRFS performance regression

#43

Post by throwii »

tobias3 wrote: post #35
throwii wrote: post #6

Earlier quoted context omitted.

Why does btrfs have those issues compared to other filesystems? I'd love to use btrfs too. Note that I deeply respect people who can write such complicated code, which I couldn't. Would Rust solve the non-speed issues? Rust-in-kernel discussion from August: https://lwn.net/Articles/829858/

My guess is this (compared to ZFS): With a CoW-file system like btrfs you have to problem that you need new file system space to delete something. This is problematic if the file system is full and you want to be able to write to it again by deleting something. ZFS solved this by just saying one can only fill a file system to 90% usage. At some point they even decreased this (during upgrade) and I had the issue that…

Interesting decision they made, I wonder whether they would decide differently now after seeing all the complexity.

So Rust does not decrease the complexity, but only removes certain kinds of errors which the compiler can detect. Neither logic errors nor speed regressions.

Thank you for your input.

Re: Linux 5.10 BTRFS performance regression

#44

Post by throwii »

panpanna wrote: post #7
throwii wrote: post #6

Earlier quoted context omitted.

Why does btrfs have those issues compared to other filesystems? I'd love to use btrfs too. Note that I deeply respect people who can write such complicated code, which I couldn't. Would Rust solve the non-speed issues? Rust-in-kernel discussion from August: https://lwn.net/Articles/829858/

Please understand that the rust memory and thread security mainly applies to "normal" applications. In kernel, you can run a privileged cache or mmu instruction or a write to some magical memory position and all the sudden the "normal" rules don't apply anymore. (But I think there are other parts of rust that are nice to have in kernel or any complex software).

I thought the Rust compiler solves issues that you wouldn't immediately see with pure C, which is why I had the idea.

I didn't know this requires certain features which are not available inside the kernel. I only knew all existing interfaces may be unsafe because they are in C though. Rust does not seem as useful then.

Thank you for your input.

Re: Linux 5.10 BTRFS performance regression

#45

Post by solarkraft »

Aardwolf wrote: post #32
turminal wrote: post #4

Earlier quoted context omitted.

The problem with btrfs is that it has quirks like that (and worse, much worse) all the time.

I had been using btrfs for 5+ years without any issues. Then a minor issue did happen, some files got missing after a system crash. That's not a problem in itself, that happens. But then I discovered that the tooling of btrfs is awful to use. Tools to repair, restore, check, scrub, ... I think I got it to finally print some filenames of missing files after a huge amount of hoops. Just see how complex btrfs restore is…

I've also been using btrfs for 5+ years. When the USB stick I keep my home server's file system on didn't boot after a power outage I stuck it into my PC, performed the simplest repair on it (don't remember which) and everything was great again.

The most annoying issue I've run into (and I really hate it) was being low on space and it being really hard to free some since it's very intransparent what's actually using it - but with btdu I mostly got that under control as well.

That said when repairing the boot drive I did experience some confusion due to there being multiple different ways - the documentation could be better on that front. For simple things at least (subvolume management, snapshot creation, checking free space) I've been quite happy with the btrfs command line tool.

Re: Linux 5.10 BTRFS performance regression

#46

Post by zaarn »

flemhans wrote: post #16
panpanna wrote: post #13

With brtfs having all kind of crazy bugs and zfs never being finished, I guess it's back to ext4...

Is ZFS not ready for use? I was going to use it in production next year.

One thing Btrfs somewhat promised was mixed disk RAIDs. Ie, having a 2TB disk and a 1TB disk and being able to say "keep 2 copies of any data in this subvolume" and "keep only 1 copy in this subvolume".

I'm currently on Bcachefs, which has erasure coding with similar promises and works better for me.

ZFS is more rigid, I have to have all matched disks for best performance, plus RAM unless I like bad performance (I don't). This could be solved by striping disks into 1TB partitions, but ZFS doesn't like living on a partitioned disk nearly as much.

Mixed disk has a bunch of cool properties for homelab users. Bcachefs also solves another problem; caching and speed. I could designate my 1TB NVMe as fast and my SATA 2TB SSDs as slow. I could also define that /tmp requiers no Erasure Coding and everything else requires 2 replicas. Then I would be able to combine the performance of my NVMe with the capacity of my SATA SSDs while gaining a simple redundance solution. My NAS has a dozen of mixed disks that I could combine more easily than ever.

The issue with ZFS is not that it's not ready to use. The issue is that it's born from enterprise and requires a costly enterprise setup to run, rather than a cheap homelab setup.

Re: Linux 5.10 BTRFS performance regression

#47

Post by cesarb »

flemhans wrote: post #16
panpanna wrote: post #13

With brtfs having all kind of crazy bugs and zfs never being finished, I guess it's back to ext4...

Is ZFS not ready for use? I was going to use it in production next year.

It can depend a lot on your definition of "ready to use".

For instance, a common threshold for "ready to use" is "included in a released version of the upstream Linux kernel, and not under CONFIG_BROKEN or CONFIG_STAGING". Under that definition, neither ZFS nor bcachefs are "ready to use".

Re: Linux 5.10 BTRFS performance regression

#48

Post by solarkraft »

m1gu3l wrote: post #5

The ratio of bad to good posts about BTRFS always made me wonder why anyone would roll with it. Don’t put your fs in crazy.

It's not as compelling to write about positive experiences.

The main competitor to btrfs is zfs, which is harder to set up, arguably more complex and has licensing issues so you can't really ship things with it built in.

I like zfs on my server, but am also happy with btrfs on my laptop.

Post reply on HN