Das Linux-Kernel 6.2 wird Verbesserungen für RAID5/6 in Btrfs enthalten.

Um das Linux-Kernel 6.2 zu aktivieren, wurden Verbesserungen an Btrfs vorgeschlagen, die sich mit dem Problem des "Write Hole" in der Implementierung von RAID 5/6 befassen. Das Hauptproblem besteht darin, dass man im Falle eines Absturzes während des Schreibvorgangs nicht sofort feststellen kann, welcher Block auf welchem der RAID-Geräte korrekt geschrieben wurde und welcher Schreibvorgang nicht abgeschlossen wurde. Bei dem Versuch, RAID in einer solchen Situation wiederherzustellen, kann es zu einer Beschädigung der Blöcke kommen, die den nicht geschriebenen Blöcken entsprechen, da der Zustand der RAID-Blöcke desynchronisiert ist. Dieses Problem tritt in allen RAID-Arrays 1/5/6 auf, in denen keine speziellen Maßnahmen zur Bekämpfung dieses Effekts ergriffen wurden.

In der RAID-Implementierung, ähnlich wie RAID1 in btrfs, wird dieses Problem durch die Verwendung von Prüfziffern in beiden Kopien gelöst; bei einer Nichtübereinstimmung werden die Daten einfach aus der zweiten Kopie wiederhergestellt. Dieser Ansatz funktioniert auch, wenn ein Gerät beginnt, fehlerhafte Daten anstelle eines vollständigen Ausfalls zu liefern.

Im Falle von RAID5/6 speichert das Dateisystem jedoch keine Prüfziffern für die Paritätsblöcke: In einer normalen Situation wird die Korrektheit der Blöcke durch die Tatsache überprüft, dass sie alle mit einer Prüfziffer versehen sind, und der Paritätsblock kann aus den Daten rekonstruiert werden. Bei einer Teilaufzeichnung kann dieser Ansatz jedoch in bestimmten Situationen scheitern. In diesem Fall ist es bei der Wiederherstellung des Arrays nicht auszuschließen, dass die von der unvollendeten Aufzeichnung betroffenen Blöcke fehlerhaft wiederhergestellt werden.

Im Fall von btrfs ist dieses Problem am relevantesten, wenn die erzeugte Schreiboperation kleiner als der Stripe ist. In diesem Fall muss das Dateisystem die Lese-Änderungs-Schreiboperation (read-modify-write, RMW) ausführen. Wenn dabei Blöcke mit unvollständigen Schreibvorgängen getroffen werden, kann die RMW-Operation Zerstörungen verursachen, die trotz der Prüfziffern nicht erkannt werden. Die Entwickler haben Änderungen vorgenommen, bei denen die RMW-Operation die Prüfziffern der Blöcke überprüft, bevor diese Operation durchgeführt wird, und im Falle einer Datenwiederherstellung auch die Überprüfung der Prüfziffern nach dem Schreiben durchführt. Leider führt dies bei der Situation mit unvollständigem Stripe (RMW) zu zusätzlichen Kosten für die Berechnung der Prüfziffern, erhöht jedoch erheblich die Zuverlässigkeit. Für RAID6 ist diese Logik noch nicht bereit, aber für einen solchen Ausfall in RAID6 muss der Schreibvorgang auf sofort 2 Geräte fehlschlagen, was weniger wahrscheinlich ist.

Zusätzlich können die Empfehlungen der Entwickler zur Verwendung von RAID5/6 hervorgehoben werden, die im Wesentlichen besagen, dass im Btrfs-Speicherprofil für Metadaten und Daten unterschiedlich sein kann. Dabei kann für Metadaten das RAID1-Profil (Spiegelung) oder sogar RAID1C3 (3 Kopien) verwendet werden, während für Daten RAID5 oder RAID6 verwendet werden kann. Dadurch wird eine zuverlässige Schutz der Metadaten und das Fehlen eines „Write Hole“ einerseits und eine effizientere Nutzung des Speicherplatzes, die für RAID5/6 charakteristisch ist, andererseits gewährleistet. Dies ermöglicht es, Zerstörungen in den Metadaten zu vermeiden, und Datenbeschädigungen können behoben werden.

Es kann auch angemerkt werden, dass für SSDs in Btrfs im Kernel 6.2 standardmäßig die asynchrone Ausführung der „Discard“-Operation (Kennzeichnung freigegebener Blöcke, die physisch nicht mehr gespeichert werden müssen) aktiviert wird. Der Vorteil dieses Modus besteht in der hohen Leistung aufgrund der effektiven Gruppierung von „Discard“-Operationen in der Warteschlange und der anschließenden Verarbeitung der Warteschlange durch den Hintergrundprozess, wodurch normale Dateisystemoperationen nicht verlangsamt werden, wie es bei der synchronen „Discard“-Operation beim Freigeben von Blöcken der Fall ist, und die SSD bessere Entscheidungen treffen kann. Andererseits ist es nicht mehr erforderlich, Dienstprogramme wie fstrim zu verwenden, da alle verfügbaren Blöcke im Dateisystem bereinigt werden, ohne dass eine zusätzliche Überprüfung erforderlich ist und ohne die Operationen zu verlangsamen.

Quelle: opennet.ru