4 ms·

Yes, it did. Here's the fix for one of the ext4 corruption bugs: https://lwn.net/Articles/645722/ https://lwn.net/Articles/645722/ (see also https://lwn.net/Art

by tagrun 6y ago

Yes, it did. Here's the fix for one of the ext4 corruption bugs: https://lwn.net/Articles/645722/ https://lwn.net/Articles/645722/ (see also https://lwn.net/Articles/645720/ https://lwn.net/Articles/645720/). The one you're referring to is https://lwn.net/Articles/774440/ 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 https://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ https://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ which was caused by an ext4-related commit, and similar others in prior years), this makes ext4 unreliable for me.

kasabali 6y ago
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.

by tagrun 6y ago

kasabali 6y ago

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.