Le dimanche 10 décembre 2023, 21 h 40 min 22 s CET Samuel Thibault a écrit :
Vincent Tondellier via FRsAG, le dim. 10 déc. 2023 21:26:00 +0100, a ecrit:
Le dimanche 10 décembre 2023, 11 h 47 min 05 s CET Romain a écrit :
Pour ceux qui auraient raté l'actu :
- https://twitter.com/debian/status/1733559140914749547
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843
Ne pas installer le paquet 6.1.64-1 du kernel.
Ca tombe bien, ca fait une semaine que mon serveur de fichier tourne avec ce noyau. J'ai du le rebooter pour patcher le bug de zfs qui pouvait corrompre le fs, et j'ai voulu éviter un autre reboot en l'installant depuis b-p-u ...
De ce que je comprends d'après les commits, ca n'affecte que les fichiers ouverts en O_DIRECT|O_SYNC|O_(RDWR|WRONLY) et en cas de crash : ils risquent de se retrouver tronqués.
Non, ça c'est le scénario corrigé par le patch fautif... Le problème c'est qu'il manquait un autre patch pour que le premier patch se comporte correctement, d'où corruption des données. Le cas qui pose problème, c'est O_DIRECT tout court, la position dans le fichier n'est pas mise à jour en fin d'opération d'entrée/sortie, de là les données peuvent être écrites un peu n'importe où.
https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/
OK, autant pour moi, je suis pas réveillé aujourd'hui, je suis effectivement parti du premier patch ...
Ca ne change pas grand chose pour moi, je n'ai pas d'applications utilisant O_DIRECT avec ext4 sur les serveurs affectés (et le serveur DB n'est pas dans le lot, encore en deb11), mais c'est effectivement un peu plus gênant ...
Le cas est donc assez peu courant vu que O_DIRECT est peu utilisé, mis a part peut être pour certaines bases de données (pas PostgreSQL en tout cas).
grep O_DIRECT dans le source de postgresql-16 indique plutôt que si.
Uniquement dans une configuration debug non standard et non recommandée :
https://www.postgresql.org/docs/current/runtime-config-developer.html#GUC-DE...
debug_io_direct dans la conf, io_direct_flags dans le code.
A ma connaissance toutes les I/O (data, wal, etc) de PostgreSQL (hors configuration exotique) utilisent le chemin classique (et bien testé) synchrone avec buffer et fdatasync.
Vincent