The EXT4 file-system today deprecated its journaled mode of the “data=journal” mount option. Following its deprecation, this mode is planned for removal in the year 2028.
The data=journal mode for EXT4 is where all file data and metadata is written to the file-system’s journal before being committed to the main file-system. In the event of a crash or power loss, the journal can then be replayed to recover the data.
The EXT4 data=journal mode is great for those very concerned about data integrity and safety but comes with significant hits to the write performance compared to the default ordered (data=ordered) mode or data=writeback. Using the journaled mode also disables delayed allocation and Direct I/O support.
EXT4 journal deprecated
Per today’s Git merge for Linux 7.3, the EXT4 data=journal feature is deprecated and support for it will be removed in early 2028 following the 2027 Linux LTS kernel version.
But why they need to remove it? Maybe just left it as a non-recommended option or just create an alternative. A great amount of people, like me for example, have a volatile enviroment that makes this a need.
Although I do prefer Btrfs for that task, I understand why some people need it in Ext4.
Most likely maintainers are looking to reduce the maintenance burden produced by a feature that had very low uptake (assuming, as others are saying, that it’s only data journalling and not metadata journalling that’s being removed).
Yeah, it might be that and that sounds fair, but still they could just make something like an external extension or module or something like that, or outright looking for someone who could make a more modern, maintenable, fast, lightweight and efficient alternative (using, i.e. io_uring).
I don’t think there’s anything preventing someone from forking it into an out-of-tree patchset or alternative module, if they’re enthusiastic about the feature. But I’m pretty sure that searching for someone to rewrite a non-core function that most people don’t care about is way outside what Linus and the various core maintainers want to do with their time. Normally open source is about people scratching their own itches.
i was going to say something along these lines – we switched at a previous last shop to something more reliable and it got rid of our problems, but our fleet was probably newer and smaller than yours; around 5k debian 8/9 bare iron servers back around 2017.