Der Linux-Kernel 6.2 wird Verbesserungen an RAID5/6 in Btrfs enthalten

Es wurden Btrfs-Verbesserungen zur Aufnahme in den Linux 6.2-Kernel vorgeschlagen, um das Schreiblochproblem in der RAID 5/6-Implementierung zu beheben. Der Kern des Problems besteht darin, dass bei einem Absturz während der Aufzeichnung zunächst nicht nachvollzogen werden kann, welcher Block auf welches RAID-Gerät korrekt geschrieben wurde und in welchen Block die Aufzeichnung nicht abgeschlossen wurde. Wenn Sie in dieser Situation versuchen, ein RAID wiederherzustellen, werden möglicherweise die Blöcke zerstört, die den unterschriebenen Blöcken entsprechen, da der Status der RAID-Blöcke nicht synchron ist. Dieses Problem tritt bei allen RAID1/5/6-Arrays auf, bei denen keine besonderen Maßnahmen zur Bekämpfung dieses Effekts ergriffen wurden.

In einer RAID-Implementierung wie RAID1 in Btrfs wird dieses Problem durch die Verwendung von Prüfsummen in beiden Kopien gelöst; bei Nichtübereinstimmung werden die Daten einfach aus der zweiten Kopie wiederhergestellt. Dieser Ansatz funktioniert auch, wenn ein Gerät statt eines Totalausfalls anfängt, falsche Daten zu senden.

Im Fall von RAID5/6 speichert das Dateisystem jedoch keine Prüfsummen für die Paritätsblöcke: Im Normalfall wird die Gültigkeit der Blöcke dadurch überprüft, dass sie alle Prüfsummen haben, und der Paritätsblock kann rekonstruiert werden aus den Daten. Bei einer teilweisen Aufzeichnung funktioniert dieser Ansatz jedoch in bestimmten Situationen möglicherweise nicht. In diesem Fall ist es beim Wiederherstellen eines Arrays möglich, dass Blöcke, die unter einen unvollständigen Datensatz fallen, falsch wiederhergestellt werden.

Im Fall von BTRFS ist dieses Problem am relevantesten, wenn der erzeugte Datensatz kleiner als der Stripe ist. In diesem Fall muss das Dateisystem einen Lese-, Änderungs- und Schreibvorgang (read-modify-write, RMW) durchführen. Wenn dabei auf Blöcke mit unvollständigem Schreibvorgang gestoßen wird, kann der RMW-Vorgang zu einer Beschädigung führen, die unabhängig von den Prüfsummen nicht erkannt wird. Die Entwickler haben Änderungen vorgenommen, bei denen die RMW-Operation die Prüfsummen der Blöcke prüft, bevor sie diese Operation durchführt, und wenn es notwendig ist, Daten wiederherzustellen, prüft sie auch die Prüfsummen nach der Aufzeichnung. Leider führt dies in einer Situation mit dem Schreiben eines unvollständigen Streifens (RMW) zu einem zusätzlichen Aufwand für die Berechnung von Prüfsummen, erhöht jedoch die Zuverlässigkeit erheblich. Für RAID6 ist eine solche Logik noch nicht bereit. Für einen solchen Fehler in RAID6 ist es jedoch erforderlich, dass der Schreibvorgang auf zwei Geräten gleichzeitig fehlschlägt, was weniger wahrscheinlich ist.

Darüber hinaus können wir Empfehlungen der Entwickler zur Verwendung von RAID5/6 feststellen, deren Kern darin besteht, dass in Btrfs die Metadaten und das Datenspeicherprofil unterschiedlich sein können. In diesem Fall können Sie das Profil RAID1 (Spiegel) oder sogar RAID1C3 (3 Kopien) für Metadaten und RAID5 oder RAID6 für Daten verwenden. Dies gewährleistet einerseits einen zuverlässigen Metadatenschutz und das Fehlen eines „Schreiblochs“ und andererseits eine effizientere Raumnutzung, die für RAID5/6 charakteristisch ist. Dadurch können Metadatenbeschädigungen vermieden und Datenbeschädigungen korrigiert werden.

Es ist auch zu beachten, dass für SSDs in Btrfs in Kernel 6.2 die asynchrone Ausführung des „Discard“-Vorgangs standardmäßig aktiviert ist (Markierung freigegebener Blöcke, die nicht mehr physisch gespeichert werden müssen). Der Vorteil dieses Modus ist eine hohe Leistung aufgrund der effektiven Gruppierung von „Verwerfen“-Vorgängen in einer Warteschlange und der Weiterverarbeitung der Warteschlange durch einen Hintergrundprozessor, weshalb normale FS-Vorgänge nicht langsamer werden, wie dies bei synchronen „Verwerfen“-Vorgängen der Fall ist. verwerfen“, wenn Blöcke freigegeben werden und die SSD bessere Entscheidungen treffen kann. Andererseits müssen Sie keine Dienstprogramme wie fstrim mehr verwenden, da alle verfügbaren Blöcke im FS gelöscht werden, ohne dass zusätzliche Scans erforderlich sind und ohne dass der Betrieb verlangsamt wird.

Source: opennet.ru

Kommentar hinzufügen