Btrfs a rétabli un worker pour la mémoire modifiée hors de son chemin normal. Le correctif protège les écritures suivantes ; il ne recrée pas les données déjà perdues.
Un correctif effectivement fusionné
La demande du 6 août de David Sterba signale une perte silencieuse de données lorsque pages ou folios modifiés n’ont pas reçu la préparation COW nécessaire. Torvalds a fusionné la restauration le même jour pour le cycle 7.2. Elle attend aussi les travaux de correction en suspens au démontage.
Le code couvre notamment une lecture en I/O directe qui modifie un mapping partagé sans réservation ordinaire d’allocation différée. L’écriture doit préparer ces blocs avant de les soumettre. Le drapeau « dirty » ne prouve donc pas que l’espace nécessaire soit réservé.
Ce que l’ancien article exagérait
Le commit de suppression contient des messages d’erreur et chemins d’avertissement pour les folios modifiés de manière inattendue. Affirmer qu’aucune ligne de journal n’existe était donc injustifié. Inversement, l’absence d’un tel message ne prouve pas que toutes les données voulues ont été conservées.
L’évaluation dépend de l’historique des correctifs : le noyau inclut-il la suppression, puis la restauration ? La fenêtre des versions candidates upstream ne décrit pas toutes les constructions dérivées ou personnalisées. La garantie générale concernant tous les noyaux de distributions a été retirée.
Un scrub sain répond à une autre question
La documentation du scrub décrit la validation des données et métadonnées stockées, dont les erreurs de lecture et de checksum. Elle ne compare pas les fichiers à l’intention de l’application.
Dans notre exemple conceptuel, le stockage contient une version A et son checksum valide. L’application voulait écrire B, mais B n’est jamais arrivé sur disque. Le scrub peut trouver A cohérent avec son checksum ; il ne possède pas une copie indépendante de B servant de référence. Ce schéma explique une limite, sans reproduire le bug du noyau.
Sur une machine ayant utilisé une construction affectée, conserver les journaux et identifier les révisions exactes permet d’établir l’exposition. Comparer les fichiers importants à une copie indépendante connue aide à évaluer leur contenu. Installer le correctif protège les écritures futures ; cela ne fournit pas rétroactivement les octets jamais écrits.
Revue du 8 septembre : correctif fusionné vérifié, généralités sur les journaux et noyaux de distributions retirées ; limites du scrub expliquées.