Ext4 data corruption in stable kernels

Posted Dec 12, 2023 18:49 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Ext4 data corruption in stable kernels by wtarreau
Parent article: Ext4 data corruption in stable kernels

As an aside, I've noted more than once in my career that there's a deep tradeoff in dependency handling here:

I can stick with an old version, and keep trying to patch it to have fewer bugs but no new features. This is less work week-by-week, but when I do hit a significant bug where I can't find a fix myself, upstream is unlikely to be much help (because I'm based on an "ancient" codebase from their point of view).
I can keep up to date with the latest version, with new features coming in all the time, doing more work week-by-week, but not having the "big leaps" to make, and having upstream much more able to help me fix any bugs I find, because I'm basing my use on a codebase that they work on every day.

For example, keeping up with latest Fedora releases is harder week-by-week than keeping up with RHEL major releases; but getting support from upstreams for the versions of packages in Fedora is generally easier than getting support for something in the last RHEL major release, because it's so much closer to their current code; further, it's generally easier to go from a "latest Fedora" version of something to "latest upstream development branch" than to go from "latest RHEL release" to "latest upstream development branch" and find patches yourself that way.

Ext4 data corruption in stable kernels

Posted Dec 13, 2023 5:54 UTC (Wed) by wtarreau (subscriber, #51152) [Link]

For me that's a tooling problem before all. For users convenience most of the time you can just upgrade to the latest version since it's supposedly better. The fact is that it's *often* better but not always, and for some users, the few cases where it's not better are so worse that they'd prefer not to *take the risk* to update. This is exactly the root cause of the problem.

What I'm suggesting is to update in small jumps, but not the last version which is still lacking feedback. If you see, say, 6.1.66 being released, and you consider that the 1-month old 6.1.62 looks correct because nobody complained about it, and nobody recently spoke about a critical urgent update that requires that everyone absolutely updates to yesterday's patch, then you could just update to 6.1.62 (or any surrounding one that was reported to work pretty well). This leaves one month of feedback for these kernels for you to choose, doesn't require too frequent updates and doesn't require to live on the bleeding edge (i.e. less risks of regressions).

That's obviously not rocket science and will not always work, but this approach allows you to skip big regressions with immediate impact, and generally saves you from having to update twice in a row.