Ihnen allen ein tolles Wochenende! Wir laden Sie zu einer kostenlosen Demo-Stunde ein. , die von Andrei Buranov, einem Spezialisten für UNIX-Systeme bei Mail.Ru Group, geleitet wird. Außerdem veröffentlichen wir einen Artikel von Jonathan Corbet, Executive Editor bei LWN.net.
Journaled Dateisysteme versprechen, Systemadministratoren von Problemen mit Festplattenschäden bei Systemausfällen zu befreien. Selbst ohne die Integrität des Dateisystems zu überprüfen. In der Realität ist natürlich alles etwas komplizierter. Wie eine kürzliche Diskussion zeigt, könnte es sogar komplizierter sein, als viele von uns denken, da die Gewährleistung der Integrität von journaled Dateisystemen die Leistung beeinflusst.
Dateisysteme wie ext3 verwenden einen separaten Bereich auf der Festplatte, der als Journal bezeichnet wird. Bei Änderungen an den Metadaten des Dateisystems werden diese Änderungen zunächst im Journal protokolliert, ohne das restliche Dateisystem zu modifizieren. Nachdem alle Änderungen im Journal protokolliert sind, wird ein "Commit-Block" hinzugefügt, der den Abschluss der Transaktion anzeigt. Erst nach der Aufzeichnung des Commit-Blocks wird die Transaktion festgeschrieben, und die geänderten Metadaten werden auf die Festplatte geschrieben. Sollte das System zu einem bestimmten Zeitpunkt ausfallen, kann mit den Informationen im Journal eine sichere Beendigung der Arbeiten erfolgen, um Beschädigungen des Dateisystems zu vermeiden, da nur ein Teil der Metadaten aktualisiert wurde.
Es gibt jedoch einen Haken: Der Code des Dateisystems muss vor dem Commit des Blocks absolut sicherstellen, dass alle Transaktionsinformationen bereits im Journal erfasst wurden. Es genügt nicht, die Operationen in der richtigen Reihenfolge zu protokollieren – moderne Festplatten unterstützen große interne Zwischenspeicher und ordnen die Operationen zur Leistungsverbesserung um. Daher muss vor dem Block-Commit ausdrücklich darauf hingewiesen werden, dass alle Journal-Daten auf die Festplatte übertragen werden. Wenn der Block-Commit zuvor geschrieben wird, kann das Journal beschädigt werden. Um dieses Problem zu lösen, werden Barrieren verwendet. Im Wesentlichen verbietet eine Barriere das Schreiben von Blöcken nach der Barriere, bis alle Blöcke, die vor der Barriere geschrieben wurden, auf die Festplatte übertragen wurden. Durch die Verwendung von Barrieren garantieren Dateisysteme die Konsistenz der Datenstrukturen.
Es gibt jedoch ein weiteres Problem: Die Dateisysteme ext3 und ext4 nutzen standardmäßig keine Barrieren. Es gibt eine Option, aber wenn der Administrator diese nicht ausdrücklich aktiviert hat, arbeiten diese Dateisysteme ohne Barrieren, obwohl in einigen Distributionen (zum Beispiel SUSE) andere Standardwerte gelten. Eric Sandeen hat kürzlich entschieden, dass hier eine Änderung notwendig ist und , der die Standardkonfigurationen für ext3 und ext4 anpasst. Und dann begann eine lebhafte Diskussion.
Andrew Morton hat sehr detailliert , warum der Standardwert genau so ist:
Beim letzten Versuch, dies zu ändern, sank die Leistung bei vielen Belastungen um 30 %, weshalb ich entsetzt alle diese Patches verworfen habe. Ich glaube, wir können das nicht riskieren und die Leistung aller Maschinen so ernsthaft verlangsamen...
Es gibt hier keine idealen Lösungen, und ich neige dazu, diese schlafende Dogge nicht zu wecken und die Standardwerte den Entwicklern der Distributionen zu überlassen.
Standardmäßig sind die Barrieren deaktiviert, da sie die Leistung erheblich beeinträchtigen. Darüber hinaus können Dateisysteme auch ohne Barrieren sehr gut funktionieren. Meldungen über Beschädigungen des ext3-Dateisystems sind selten und kommen nur in wenigen Fällen vor.
Aber das ist nicht nur Glück. Ted Ts'o liegt daran, dass das Journal von ext3/ext4 normalerweise kontinuierlich platziert wird. Erstens versucht der Dateisystemtreiber, es kontinuierlich zu gestalten. Zweitens wird das Journal normalerweise gleichzeitig mit dem Dateisystem erstellt, wenn einfach kontinuierlicher Platz gefunden werden kann. Kontinuität und Ordnung sind nicht nur für die Leistung von Vorteil, sondern helfen auch, eine Umordnung zu verhindern. Normalerweise wird der Commit-Block sofort nach den anderen Daten im Journal platziert, sodass es für die Festplatte keinen Grund zur Umordnung gibt. Der Commit-Block wird auf natürliche Weise sofort nach den anderen Journal-Einträgen auf die Festplatte geschrieben.
Dennoch behauptet niemand, dass es immer so sein wird. Festplattenspeicher können sich auch anders verhalten. Zudem ist das Journal ein ringpuffer. Daher kann es vorkommen, dass ein Commit-Block in einem früheren Block geschrieben wird, bevor andere Journal-Einträge vorliegen. Das Risiko einer Beschädigung besteht also immer. Tatsächlich hat Chris Mason dafür . Es besteht kein Zweifel, dass der Betrieb ohne Barrieren weniger sicher ist als mit ihnen.
Wenn Sie bereit sind, einen Leistungseinbruch hinzunehmen, können Sie die Barrieren aktivieren. Vorausgesetzt, Ihr Dateisystem basiert nicht auf LVM (wie in einigen Distributionen standardmäßig). Es stellt sich heraus, dass der Device Mapper Barrieren nicht unterstützt. In anderen Fällen wäre es gut, den Leistungseinbruch zu minimieren. Und es scheint, dass dies möglich ist.
Die aktuelle Implementierung von ext3 (wenn Barrieren aktiviert sind) führt für jede Transaktion die folgende Abfolge von Operationen aus:
Daten werden ins Journal geschrieben
Ein Barrier wird ausgeführt
Ein Commit-Block wird geschrieben
Der nächste Barrier wird ausgeführt
Später werden Metadaten auf die Festplatte geschrieben
Im ext4 kann die erste Barriere (Schritt 2) übersprungen werden, da das ext4-Dateisystem Prüfziffern im Journal unterstützt.
Wenn die Journaldaten und der Commit-Block umgeordnet sind und der Vorgang aufgrund eines Fehlers unterbrochen wird, wird die Prüfziffer des Journals nicht mit der im Commit-Block übereinstimmen und die Transaktion wird abgelehnt.
Chris Mason , was bedeuten würde, dass es "im Allgemeinen sicher" wäre, diese Barriere auch im ext3 zu entfernen, mit der möglichen Ausnahme, wenn das Journal das Ende erreicht und von vorne zu schreiben beginnt.
Eine weitere Idee zur Beschleunigung ist, Operationen mit Barrieren, wann immer möglich, zu verzögern. Wenn es nicht unbedingt erforderlich ist, die Daten sofort auf die Festplatte zu schreiben, können mehrere Transaktionen im Journal creación und mit einer einzigen Barriere auf die Festplatte geschrieben werden.
Es besteht auch ein gewisses Potenzial zur Verbesserung durch eine sorgfältige Anordnung der Operationen, sodass Barrieren (die normalerweise in Form von Anfragen „alle verzögerten Operationen auf die Festplatte schreiben“) nicht die Aufzeichnung von Blöcken erzwingen, die keine Reihenfolge erfordern.
Es scheint an der Zeit zu sein, darüber nachzudenken, wie die Kosten für Barrieren akzeptabel gemacht werden können. Ted Tso scheint :
Ich denke, wir sollten Barrieren in ext3/4 einfügen und dann an der Reduzierung der Overheads in ext4/jbd2 arbeiten. Höchstwahrscheinlich funktionieren die meisten Systeme nicht unter Bedingungen, wie sie Chris zur Demonstration des Problems verwendet hat, und die Sicherheit des Dateisystems sollte immer an erster Stelle stehen.
Der gesunde Menschenverstand sagt mir, dass dieser Hund wahrscheinlich nicht mehr schläft und wahrscheinlich eine Zeit lang bellen wird. Das könnte einige Nachbarn beunruhigen, aber es ist besser, als ihn beißen zu lassen.
Möchten Sie sich in diesem Bereich weiterentwickeln? Melden Sie sich für eine kostenlose Demo-Stunde an und nehmen Sie an der Übertragung teil , moderiert von Pawel Vikiryuk — MVNO-Kommunikationsoperator, DevOps-Ingenieur.
Quelle: habr.com
