EXT4 déprécie son mode data=journal et prévoit de le retirer début 2028
Le 8 octobre 2026, la fusion Git de Linux 7.3 déprécie le mode data=journal d’EXT4, qui écrit données et métadonnées dans le journal avant de les valider, et programme sa suppression début 2028. Vérifiez vos options de montage dans /etc/fstab : si vous n’activez pas data=journal explicitement, cette dépréciation ne vous concerne pas.
8 octobre 2026. Michael Larabel rapporte sur Phoronix que le système de fichiers EXT4 a déprécié son mode journalisé, l’option de montage data=journal. Début 2028. C’est l’échéance annoncée pour la suppression définitive de ce mode, après le noyau LTS de 2027. Linux 7.3. C’est la version qui embarque la dépréciation, via la fusion Git du jour. Pourquoi c’est important : data=journal est l’option la plus sûre d’EXT4 contre la perte de données après une coupure, et ceux qui s’en servent explicitement ont trois ans pour migrer.
Ce que fait data=journal
Pour comprendre la dépréciation, il faut revenir au rôle du journal dans un système de fichiers. EXT4 dispose d’un journal (journaling) qui enregistre les opérations avant qu’elles ne soient appliquées au système de fichiers principal. En cas de crash ou de coupure d’alimentation, le journal est rejoué au montage suivant pour réparer un état incohérent.
Le mode data=journal pousse cette logique à son maximum. Avec cette option, toutes les données des fichiers — pas seulement les métadonnées — sont écrites dans le journal avant d’être validées dans le système de fichiers principal. Chaque écriture de donnée transite donc par le journal, puis par sa destination finale.
C’est le mode le plus sûr d’EXT4 pour l’intégrité des données. Une coupure de courant au mauvais moment laisse moins de place à la corruption, puisque la donnée est dans le journal avant d’être déplacée. Pour des charges où aucune perte n’est tolérable, c’est une garantie appréciable.
Le mode par défaut, lui, est data=ordered. Il n’écrit dans le journal que les métadonnées, et ordonne les écritures pour que les données soient sur le disque avant que les métadonnées ne les référencent. C’est un compromis qui protège la structure du système de fichiers sans payer le coût de la double écriture des données.
Le prix à payer : double écriture et fonctions désactivées
La garantie de data=journal se paie cher, et c’est précisément ce coût qui le condamne.
Le premier prix, c’est la performance en écriture. Chaque donnée est écrite deux fois — une fois dans le journal, une fois dans le système de fichiers. Phoronix parle d’un impact significatif sur les performances d’écriture par rapport aux modes data=ordered ou data=writeback. Sur un serveur ou une base de données, ce surcoût se traduit directement en latence et en débit perdu.
Le second prix est plus subtil : le mode data=journal désactive deux optimisations majeures d’EXT4. Il coupe l’allocation différée (delayed allocation), qui regroupe les écritures pour réduire la fragmentation et améliorer le débit. Il désactive aussi le support de l’E/S directe (Direct I/O), qui permet aux applications — les bases de données en tête — de contourner le cache du noyau.
Le résultat est une combinaison pénalisante. data=journal ralentit les écritures ordinaires par la double écriture, et il désactive les mécanismes qui permettraient de compenser. C’est un mode pensé pour la sûreté maximale, au prix d’une machine qui écrit lentement.
Pourquoi maintenant : maintenir moins de chemins de code
La dépréciation n’est pas motivée par une faille, mais par la maintenance. Le mode data=journal emprunte un chemin de code distinct dans EXT4, avec sa propre gestion des écritures journalisées, son interaction propre avec l’allocation et l’E/S directe — et il est peu utilisé.
Un chemin de code rarement exercé est un risque en soi. Il reçoit moins de tests, moins de retours, et chaque refonte du reste du système de fichiers doit composer avec lui. Le retirer simplifie le noyau et réduit la surface à maintenir. La trajectoire est classique dans le noyau Linux : déprécier d’abord, retirer plus tard, après avoir laissé aux utilisateurs le temps de migrer.
Le calendrier est annoncé : dépréciation dans Linux 7.3, suppression début 2028, après le noyau LTS de 2027. Le fait de caler la suppression après un LTS est une précaution délibérée : ceux qui figent leur noyau sur un LTS ont la garantie que le mode reste disponible sur cette branche, même après sa disparition des versions récentes.
Que vérifier dans votre fstab
La question pratique tient en une commande. Le mode de journalisation se règle à l’option de montage, donc il se lit dans /etc/fstab ou dans la sortie de mount.
# Chercher une option data=journal sur les montages EXT4
grep -E 'ext4' /etc/fstab | grep -o 'data=[a-z]*'
# Ou interroger le montage actif
findmnt -t ext4 -o TARGET,OPTIONSLe diagnostic est binaire. Si aucune ligne ne mentionne data=journal, vous utilisez le mode par défaut data=ordered (ou un data=writeback explicite) et la dépréciation ne vous concerne pas. Si une ligne porte data=journal, vous avez trois ans pour changer.
La migration est simple dans l’immense majorité des cas : retirer l’option et laisser le défaut data=ordered reprendre la main. Pour les charges qui exigeaient la garantie maximale de data=journal, la vraie réponse est ailleurs — une application qui ne tolère aucune perte doit s’appuyer sur fsync() au bon moment, pas sur un mode de montage qui double toutes les écritures. data=ordered protège déjà l’intégrité de la structure du système de fichiers ; il ne protège pas, à lui seul, la durabilité d’une transaction applicative — mais data=journal ne le faisait pas mieux sans les fsync correspondants.
La vraie garantie de durabilité s’appelle fsync
Retirer data=journal ne revient pas à abandonner la durabilité : cela force à la remettre au bon endroit. Le mode journalisé donnait une impression de sécurité — toutes les données transitaient par le journal — mais cette sécurité restait incomplète sans la coopération des applications.
La raison tient à la façon dont le noyau et les applications se parlent. Une application qui écrit un fichier confie ses données au cache du noyau ; elles ne sont pas immédiatement sur le disque. Seul l’appel fsync() force l’écriture effective, et c’est lui qui garantit la durabilité d’une transaction — pas le mode de montage.
Les bases de données le savent depuis toujours. PostgreSQL, MySQL ou SQLite émettent des fsync() au moment de valider une transaction, précisément parce que c’est le seul moyen portable de garantir qu’une écriture survivra à une coupure. Un data=journal sans ces fsync() ne protège pas mieux une base qu’un data=ordered avec eux.
La conséquence pratique est libératrice. Si une charge exige une durabilité forte, la réponse est dans l’application — des fsync() correctement placés — et non dans une option de montage qui double toutes les écritures en permanence. Migrer de data=journal vers data=ordered, c’est donc aussi l’occasion de vérifier que les applications critiques font bien leur part.
Verdict
Si vous n’avez jamais écrit data=journal dans une configuration de montage, vous n’avez rien à faire : le mode par défaut data=ordered n’est pas touché, et cette dépréciation est une simplification du noyau qui vous est invisible. Si vous utilisez explicitement data=journal pour des charges sensibles à la perte de données, profitez des trois ans qui restent pour migrer — retirez l’option au profit du défaut, et déplacez la garantie de durabilité vers des fsync() explicites dans les applications, qui est la méthode correcte et portable. Dans tous les cas, ne confondez pas la dépréciation du mode avec une dépréciation d’EXT4 lui-même : le système de fichiers reste le défaut de la plupart des distributions, seul un mode optionnel, lent et rare, tire sa révérence.