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

201–202 of 202 posts

Re: Linux 5.10 BTRFS performance regression

#201

Post by nasir_hm »

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!

Thank You very much for the hard work you do Greg, You're awesome :D

Re: Linux 5.10 BTRFS performance regression

#202

Post by tagrun »

kasabali wrote: post #195
tagrun wrote: post #193

Earlier quoted context omitted.

Yes, it did. Here's the fix for one of the ext4 corruption bugs: https://lwn.net/Articles/645722/ (see also https://lwn.net/Articles/645720/ ). The one you're referring to is https://lwn.net/Articles/774440/ which is a different bug. I should add that as a user, what matters to me is the reliability of my data. If a bug exists outside of fs/ext4 in the kernel but affects only ext4 and not other filesystems (such as h…

You claimed there were two critical data corruption bugs in the past 5 years, one which was debunked as a not ext4 bug and the other one you linked is from April 2015, which happened more than 5 years ago. > which was caused by an ext4-related commit Now that's blatantly wrong. It wasn't caused by an ext4-related commit. The commit to blame was scheduler code in the block layer. Nothing filesystem specific.

You're arguing that it happened 5 years and 7 months ago, which is more than 5 years, so all is well with ext4. Seriously?

The point is, ext4 isn't a monument of reliability like you delude yourself with, and it had, and will continue having data corruption bugs.

> Now that's blatantly wrong. It wasn't caused by an ext4-related commit.

Yes it was. This is very clear from the context: https://patchwork.ozlabs.org/project/linux-ext4/patch/500F1C...

You can try and weasel your way out with the semantics, say that it didn't change any files under ext4/ (which does happen with xfs/btrfs/... related patches too BTW, simply because fs/ contains common fs code), but the reality is, it was an ext4 related fix, it appeared in "linux-ext4" mailing list, and Ted Tso, the ext4 maintainer, signed off the patch.

Lastly, idolizing a piece of code is nonsensical. Yes, btrfs had its data corruption bugs, but you can't pretend that ext4 and other filesystems didn't.

Post reply on HN