Pour le noyau Linux 6.2, des améliorations Btrfs ont été proposées concernant la correction du problème du « write hole » dans l'implémentation RAID 5/6. Le problème réside dans le fait que si une panne se produit pendant l'écriture, il est initialement impossible de savoir quel bloc a été correctement écrit sur lequel des appareils RAID, et où l'écriture n'a pas été terminée. Lors de la tentative de récupération du RAID dans une telle situation, il peut y avoir une destruction des blocs correspondant aux blocs non écrits, car l'état des blocs RAID est désynchronisé. Ce problème apparaît dans tous les ensembles RAID1/5/6 où aucune mesure spéciale n'est prise pour lutter contre cet effet.
Dans l'implémentation RAID, comme RAID1 dans btrfs, ce problème est résolu par l'utilisation de sommes de contrôle sur les deux copies : en cas de non-coïncidence, les données sont simplement récupérées à partir de la deuxième copie. Cette approche fonctionne également si un appareil commence à fournir des données incorrectes au lieu d'une panne complète.
Cependant, dans le cas de RAID5/6, le système de fichiers ne stocke pas de sommes de contrôle pour les blocs de parité : dans une situation normale, l'intégrité des blocs est vérifiée par le fait qu'ils sont tous dotés d'une somme de contrôle, et le bloc de parité peut être recréé à partir des données. Cependant, en cas d'écriture partielle, cette approche peut ne pas fonctionner dans certaines situations. Dans ce cas, lors de la restauration de l'ensemble, il n'est pas exclu que les blocs concernés par une écriture inachevée soient récupérés de manière incorrecte.
Dans le cas de btrfs, ce problème est particulièrement pertinent lorsque l'écriture produite est inférieure à la taille d'un stripe. Dans ce cas, le système de fichiers doit effectuer une opération de lecture-modification-écriture (read-modify-write, RMW). Si des blocs avec une écriture incomplète se présentent, l'opération RMW peut entraîner des corruptions qui ne seront pas détectées, malgré les sommes de contrôle. Les développeurs ont apporté des modifications pour que l'opération RMW vérifie la somme de contrôle des blocs avant d'effectuer cette opération, et, en cas de restauration des données, effectue également une vérification des sommes de contrôle après l'écriture. Malheureusement, dans la situation d'une écriture d'un stripe incomplet (RMW), cela entraîne des frais supplémentaires pour le calcul des sommes de contrôle, mais augmente considérablement la fiabilité. Pour RAID6, cette logique n'est pas encore prête, cependant, pour une telle défaillance dans RAID6, il est nécessaire que l'écriture échoue sur 2 appareils en même temps, ce qui est moins probable.
On peut également noter les recommandations des développeurs concernant l'utilisation de RAID5/6, qui consistent en ce que, dans Btrfs, le profil de stockage des métadonnées et des données peut différer. Dans ce cas, un profil RAID1 (miroir) ou même RAID1C3 (3 copies) peut être utilisé pour les métadonnées, tandis que RAID5 ou RAID6 peut être utilisé pour les données. Cela permet d'assurer une protection fiable des métadonnées et d'éviter le « write hole » d'une part, et d'autre part un usage plus efficace de l'espace, caractéristique de RAID5/6. Cela évite les corruptions dans les métadonnées, tandis que les dommages aux données peuvent être corrigés.
Il convient également de noter que pour les SSD, dans Btrfs, le noyau 6.2 activera par défaut l'exécution asynchrone de l'opération « discard » (marquage des blocs libérés qui ne doivent plus être stockés physiquement). L'avantage de ce mode est sa haute performance grâce à une gestion efficace des opérations « discard » dans une file d'attente, suivie d'un traitement par un gestionnaire en arrière-plan, ce qui évite que les opérations normales du FS ne ralentissent, comme c'est le cas avec un « discard » synchrone lors de la libération des blocs, et le SSD peut prendre des décisions plus avantageuses. D'autre part, il ne sera plus nécessaire d'utiliser des utilitaires comme fstrim, puisque tous les blocs disponibles seront nettoyés dans le FS sans nécessité de scans supplémentaires et sans ralentissement des opérations.
Source : opennet.ru
