|
|
Subscribe / Log in / New account

Ext4 data corruption in stable kernels

Ext4 data corruption in stable kernels

Posted Dec 10, 2023 13:04 UTC (Sun) by mb (subscriber, #50428)
In reply to: Ext4 data corruption in stable kernels by rolexhamster
Parent article: Ext4 data corruption in stable kernels

>Filesystems should not eat data. Was that commit really necessary for backporting to stable?

By your own reasoning that filesystems should not eat data, it was necessary.

From the commit message:

>on ext4 O_SYNC direct IO does not properly
>sync file size update and thus if we crash at unfortunate moment, the
>file can have smaller size although O_SYNC IO has reported successful
>completion.

It was supposed to prevent data corruption.
-> "Filesystems should not eat data."
-> We must apply it to stable a.s.a.p.

>Maybe it would be useful to classify stuff sent to stable@kernel as high/med/low risk,
>based on what subsystem it touches.

And that would have prevented this fix from being applied to stable?
I doubt it. It was supposed to avoid corruption.

I am not saying that things went well here and I am not saying the stable process is perfect.
But in reality such problems happen rarely in stable.
Stable is not supposed to be an enterprise kernel. It is supposed to collect fixes with the least amount of manual work possible. That is guaranteed to introduce bugs sooner or later. But I think it's the best we can do at this level.

I don't think any kind of risk classification can help here.
It's basically the same problem as with security fixes. People will just start to argue whether a fix actually is really needed or not. And wrong decisions will then be made. Which will also lead to buggy stable kernels.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds