3 ms·

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 Apri

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.

tagrun 6y ago
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/500F1C28.8010800@redhat.com/ 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.