Des améliorations Btrfs ont été proposées pour inclusion dans le noyau Linux 6.2 afin de résoudre le problème du « trou d'écriture » dans l'implémentation RAID 5/6. L'essence du problème réside dans le fait que si un crash se produit pendant l'enregistrement, il est initialement impossible de comprendre sur quel bloc sur quel périphérique RAID a été écrit correctement et dans lequel l'enregistrement n'a pas été terminé. Si vous tentez de restaurer un RAID dans cette situation, les blocs correspondant aux blocs souscrits risquent d'être détruits car l'état des blocs RAID est désynchronisé. Ce problème se produit dans toutes les matrices RAID1/5/6 pour lesquelles aucune mesure spéciale n'a été prise pour lutter contre cet effet.
Dans une implémentation RAID, comme RAID1 dans btrfs, ce problème est résolu en utilisant des sommes de contrôle dans les deux copies ; en cas de disparité, les données sont simplement restaurées à partir de la deuxième copie. Cette approche fonctionne également si un appareil commence à envoyer des données incorrectes au lieu d'une panne totale.
Cependant, dans le cas de RAID5/6, le système de fichiers ne stocke pas les sommes de contrôle des blocs de parité : dans une situation normale, la validité des blocs est vérifiée par le fait qu'ils sont tous additionnés, et le bloc de parité peut être reconstruit. à partir des données. Toutefois, dans le cas d’un enregistrement partiel, cette approche peut ne pas fonctionner dans certaines situations. Dans ce cas, lors de la restauration d'un tableau, il est possible que les blocs relevant d'un enregistrement incomplet soient restaurés de manière incorrecte.
Dans le cas des btrfs, ce problème est particulièrement pertinent si le disque produit est plus petit que la bande. Dans ce cas, le système de fichiers doit effectuer une opération de lecture-modification-écriture (lecture-modification-écriture, RMW). Si cela rencontre des blocs avec une écriture incomplète, l'opération RMW peut provoquer une corruption qui ne sera pas détectée, quelles que soient les sommes de contrôle. Les développeurs ont apporté des modifications dans lesquelles l'opération RMW vérifie la somme de contrôle des blocs avant d'effectuer cette opération, et s'il est nécessaire de restaurer les données, elle vérifie également les sommes de contrôle après l'enregistrement. Malheureusement, dans le cas de l'écriture d'une bande incomplète (RMW), cela entraîne une surcharge supplémentaire pour le calcul des sommes de contrôle, mais augmente considérablement la fiabilité. Pour RAID6, une telle logique n'est pas encore prête, cependant, pour une telle panne en RAID6, il faut que l'écriture échoue sur 2 périphériques à la fois, ce qui est moins probable.
De plus, nous pouvons noter les recommandations des développeurs pour l'utilisation de RAID5/6, dont l'essentiel est que dans Btrfs, les métadonnées et le profil de stockage des données peuvent différer. Dans ce cas, vous pouvez utiliser le profil RAID1 (miroir) ou encore RAID1C3 (3 copies) pour les métadonnées, et RAID5 ou RAID6 pour les données. Cela garantit une protection fiable des métadonnées et l'absence de « trou d'écriture », d'une part, et une utilisation plus efficace de l'espace, caractéristique du RAID5/6, d'autre part. Cela permet d'éviter la corruption des métadonnées et de corriger la corruption des données.
On peut également noter que pour les SSD en Btrfs dans le noyau 6.2, l'exécution asynchrone de l'opération « discard » sera activée par défaut (marquage des blocs libérés qui n'ont plus besoin d'être physiquement stockés). L'avantage de ce mode est la haute performance due au regroupement efficace des opérations de « rejet » dans une file d'attente et au traitement ultérieur de la file d'attente par un processeur d'arrière-plan, c'est pourquoi les opérations FS normales ne ralentissent pas, comme c'est le cas avec les opérations synchrones. «jeter» à mesure que les blocs sont libérés et que le SSD peut prendre de meilleures décisions. D'un autre côté, vous n'aurez plus besoin d'utiliser des utilitaires comme fstrim, puisque tous les blocs disponibles seront effacés dans le FS sans avoir besoin d'une analyse supplémentaire et sans ralentir les opérations.
Source: opennet.ru