HAMMER2 cannot be ready soon enough.
Linux 5.10 BTRFS performance regression
21–30 of 202 posts
Re: Linux 5.10 BTRFS performance regression
#22The 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.
Didn't Fedora transition to BTRFS as default in 33? I'm eager to see reports from that.
Re: Linux 5.10 BTRFS performance regression
#23With 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.
ZoL != OpenZFS != ZoF. A lot has changed recently, so you'll have to clarify the platform and version.
ZFS on FUSE should be deprecated by now, and ZoL I believe merged with OpenZFS for the 2.0 release.
FreeBSD ZFS is fine, and just check your versions if using it on Linux. Ie- don't use anything pre-2.0.
Re: Linux 5.10 BTRFS performance regression
#24With brtfs having all kind of crazy bugs and zfs never being finished, I guess it's back to ext4...
Is any software ever finished?
ZFS has been quite feature-full and production ready for more than a decade... why do you think it is not finished?
Re: Linux 5.10 BTRFS performance regression
#25This 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…
And the fstrim issue: http://lkml.iu.edu/hypermail/linux/kernel/2012.1/01288.html
Which triggered an immediate 5.10.1 release: http://lkml.iu.edu/hypermail/linux/kernel/2012.1/07005.html
Re: Linux 5.10 BTRFS performance regression
#26The 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.
The ratio of bad to good posts has always stunned me too. But for the opposite reason. The linked post explains that there is a performance regression in a very rare and specific usecase: creating 100k files in a short span of time. And I'm not talking about unpacking boost, that's not enough files. Additionally, it will be fixed before any distro packages it. (even Arch is still on 5.9.14.) On the other hand btrfs g…
Not btrfs and anecdotal but fedora 33 / 5.8 kernel / default gnome was unusable for me on amd r5 3500U. Headphone microphone didn’t work. Bluetooth ear phones and mic didn’t work. USB headphone microphone worked though. Sure enough most of the issues were resolved by 5.9 but I can no longer recommend Linux on the desktop.
Re: Linux 5.10 BTRFS performance regression
#27Earlier 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/
I sincerely hope you are joking but I realize this mindset is quite common these days, so let me reiterate: Rust does not magically solve problems for you. Btrfs has a lot of issues and some of them may well be of the not possible in Rust sort, but I'm quite sure most of them are not and there is nothing Rust can fix about them. Rewriting a 13 years old and very complex thing in another language is a massive effort a…
It is like a repeating story, every time someone sells the magically solution to all problems and apply a name on it people blindly believe it.
This are tools. A screwdriver is not the right tool, when you need a power drill. And vice versa. Yes, sometimes you can use both and stick with your accustomed tool.
Anyway. C and C++ and the tool chain are constantly improving like others.The moern memory sanitizers in GCC and LLVM are awesome.
Re: Linux 5.10 BTRFS performance regression
#28Earlier quoted context omitted.
Nobody posts about things that are working fine.
Does OpenZFS have a similar ratio of bad to good posts?
ZFS's killer feature is religious inspiration.
Write holes during resilvers are healthy and natural, but the same in a software RAID 5/6 configuration on BTRFS is unacceptably risky.
Brought to you by the same people who don't think SMR disks are used with ZFS in enterprise.
Re: Linux 5.10 BTRFS performance regression
#29Earlier quoted context omitted.
The ratio of bad to good posts has always stunned me too. But for the opposite reason. The linked post explains that there is a performance regression in a very rare and specific usecase: creating 100k files in a short span of time. And I'm not talking about unpacking boost, that's not enough files. Additionally, it will be fixed before any distro packages it. (even Arch is still on 5.9.14.) On the other hand btrfs g…
Not btrfs and anecdotal but fedora 33 / 5.8 kernel / default gnome was unusable for me on amd r5 3500U. Headphone microphone didn’t work. Bluetooth ear phones and mic didn’t work. USB headphone microphone worked though. Sure enough most of the issues were resolved by 5.9 but I can no longer recommend Linux on the desktop.
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 linux, mostly to do with interaction of linux and your machine manufacturer.