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-DEBUG-IO-DIRECT 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 _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
