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. Romain
Hello, Normalement le paquet linux-image 6.1.66-1 est dans bookworm-proposed-updates et devrait être dans bookworm dans les heures qui viennent si tout va bien (Merci à Cyril Brulebois pour l'info). Il faut passer au 6.1.66-1 directement. On Sun, Dec 10, 2023 at 11:48 AM Romain <romain@borezo.info> wrote:
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.
Romain _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
A mettre dans /etc/apt/preferences.d/buggy-kernel : with the contents: # avoid kernel with ext4 bug # 1057843 Package: linux-image-* Pin: version 6.1.64-1 Pin-Priority: -1 Ça permet de rester en 6.1.52-1 et de recevoir la 6.1.66-1 quand elle sera disponible. Romain Le dim. 10 déc. 2023 à 11:47, Romain <romain@borezo.info> 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.
Romain
Version 12.4 dispo, problème réglé :) Le dim. 10 déc. 2023 à 18:26, Romain <romain@borezo.info> a écrit :
A mettre dans /etc/apt/preferences.d/buggy-kernel : with the contents: # avoid kernel with ext4 bug # 1057843 Package: linux-image-* Pin: version 6.1.64-1 Pin-Priority: -1
Ça permet de rester en 6.1.52-1 et de recevoir la 6.1.66-1 quand elle sera disponible.
Romain
Le dim. 10 déc. 2023 à 11:47, Romain <romain@borezo.info> 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.
Romain
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. 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). Donc on est loin du kernel radioactif qui détruit toutes les données, même si il vaut mieux l'éviter par précaution ...
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/
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. De manière générale c'est pas tellement utilisé en effet, mais pour des bases de données qui veulent optimiser l'ordonnancement des écritures, si. Samuel
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
participants (4)
-
Romain -
Samuel Thibault -
Vincent Tondellier -
Yves Rougy