Allen ein hervorragendes Wochenende! Wir laden zu einem kostenlosen Demo-Kurs ein , den Andrei Buranov â Spezialist fĂŒr UNIX-Systeme bei Mail.Ru Group â leitet. AuĂerdem veröffentlichen wir einen Artikel von Jonathan Corbet â Executive Editor bei LWN.net.
Journalierte Dateisysteme versprechen, Systemadministratoren von Problemen mit FestplattenschĂ€den bei SystemausfĂ€llen zu befreien. Sogar ohne die AusfĂŒhrung der IntegritĂ€tsprĂŒfung des Dateisystems. In der RealitĂ€t ist natĂŒrlich alles etwas komplizierter. Und wie eine kĂŒrzliche Diskussion zeigt, kann es sogar verwirrender sein, als viele von uns denken, da die Sicherstellung der IntegritĂ€t von journalisierten Dateisystemen die Leistung beeinflusst.
Ein Dateisystem wie ext3 nutzt einen separaten Bereich auf der Festplatte, der als Journal bezeichnet wird. Bei Ănderungen an den Metadaten des Dateisystems werden diese Ănderungen zuerst in das Journal geschrieben, ohne das restliche Dateisystem zu modifizieren. Nach dem Schreiben aller Ănderungen in das Journal wird ein âCommit-Blockâ hinzugefĂŒgt, der das Ende der Transaktion anzeigt. Erst nach dem Schreiben des Commit-Blocks wird die Transaktion fixiert und die geĂ€nderten Metadaten werden auf die Festplatte geschrieben. Wenn das System irgendwann ausfĂ€llt, kann mit den Informationen im Journal sicher abgeschlossen und SchĂ€den am Dateisystem vermieden werden, da nur ein Teil der Metadaten aktualisiert wurde.
Es gibt jedoch einen Haken: Der Code des Dateisystems muss vor dem Schreiben des Commit-Blocks absolut sicher sein, dass alle Informationen zur Transaktion bereits im Journal sind. Es reicht nicht aus, die VorgĂ€nge in der richtigen Reihenfolge zu schreiben â moderne Festplatten unterstĂŒtzen groĂe interne Caches und ordnen VorgĂ€nge zur Leistungsverbesserung neu an. Daher muss vor dem Commit-Block ausdrĂŒcklich angegeben werden, dass alle Journal-Daten auf die Festplatte ĂŒbertragen werden. Wenn der Commit-Block zu frĂŒh geschrieben wird, kann das Journal beschĂ€digt werden. Zur Lösung dieses Problems werden Barrieren eingesetzt. Im Wesentlichen verbietet eine Barriere das Schreiben von Blöcken nach der Barriere, bis alle vor der Barriere geschriebenen Blöcke auf die Festplatte ĂŒbertragen sind. Durch die Verwendung von Barrieren gewĂ€hrleisten Dateisysteme die Konsistenz der Datei-strukturen.
Es gibt jedoch ein weiteres Problem: Die Dateisysteme ext3 und ext4 verwenden standardmĂ€Ăig keine Barrieren. Es gibt eine Option, aber wenn der Administrator sie nicht ausdrĂŒcklich aktiviert hat, arbeiten diese Dateisysteme ohne Barrieren, obwohl in einigen Distributionen (zum Beispiel SUSE) die Standardwerte anders sind. Eric Sandeen hat kĂŒrzlich beschlossen, dass man diese Situation Ă€ndern muss und , der die Standardkonfigurationen fĂŒr ext3 und ext4 modifiziert. Und dann begann eine lebhafte Diskussion.
Andrew Morton hat sehr ausfĂŒhrlich , warum der Standardwert genau so ist:
Beim letzten Versuch, dies zu Ă€ndern, hat sich die Leistung bei vielen Lasten um 30 % verschlechtert, daher habe ich entsetzt alle diese Patches verworfen. Ich denke, wir können es uns nicht leisten, die Leistung aller Maschinen so ernsthaft zu verlangsamenâŠ
Es gibt keine perfekten Lösungen, und ich neige dazu, diese schlafenden Hunde nicht zu wecken und die Standardparameter den Entwicklern der Distributionen zu ĂŒberlassen.
Somit sind Barrieren standardmĂ€Ăig deaktiviert, da sie die Leistung erheblich beeinflussen. DarĂŒber hinaus werden die Dateisysteme durchaus erfolgreich ohne Barrieren genutzt. Berichte ĂŒber BeschĂ€digungen beim ext3-Dateisystem sind rare Ausnahmen.
Aber das ist nicht einfach GlĂŒck. Ted Ts'o liegt daran, dass das Journal bei ext3/ext4 normalerweise kontinuierlich angelegt wird. Erstens versucht der Treiber des Dateisystems, es kontinuierlich zu erstellen. Zweitens wird das Journal in der Regel gleichzeitig mit dem Dateisystem erstellt, wenn es einfach ist, einen kontinuierlichen Speicherplatz zu finden. KontinuitĂ€t und Ordnung sind nicht nur fĂŒr die Leistung nĂŒtzlich, sondern auch, um eine Neuanordnung zu verhindern. Normalerweise wird der Commit-Block direkt nach den anderen Daten im Journal platziert, sodass es fĂŒr das Laufwerk keinen Grund gibt, umzustrukturieren. Der Commit-Block wird natĂŒrlich unmittelbar nach den anderen Journalaufzeichnungen auf das Laufwerk geschrieben.
Dennoch behauptet niemand, dass dies immer so sein wird. Festplatten können sich auch anders verhalten. DarĂŒber hinaus ist das Journal ein Ringpuffer. Wenn eine Transaktion also ans Ende des Journals geschrieben wird, kann der Commit-Block in einem frĂŒheren Block erscheinen, vor anderen Journalaufzeichnungen. Daher besteht immer die Wahrscheinlichkeit einer BeschĂ€digung. TatsĂ€chlich hat Chris Mason dafĂŒr Es besteht kein Zweifel, dass die Arbeit ohne Barrieren weniger sicher ist als mit ihnen.
Wenn Sie bereit sind, einen Leistungseinbruch in Kauf zu nehmen, können Sie die Barrieren aktivieren. Vorausgesetzt, Ihr Dateisystem basiert nicht auf LVM (wie es bei einigen Distributionen standardmĂ€Ăig der Fall ist). Es stellt sich heraus, dass der Device Mapper Barrieren nicht unterstĂŒtzt. In anderen FĂ€llen wĂ€re es nicht schlecht, den Leistungsverlust zu verringern. Und anscheinend lĂ€sst sich das umsetzen.
Die aktuelle Implementierung von ext3 (wenn Barrieren aktiviert sind) fĂŒhrt fĂŒr jede Transaktion die folgende Folge von Operationen aus:
Daten werden in das 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
In ext4 kann der erste Barrier (Schritt 2) weggelassen werden, da das Dateisystem ext4 PrĂŒfziffern im Journal unterstĂŒtzt.
Wenn die Journal-Daten und der Commit-Block neu angeordnet sind und die Operation infolge eines Fehlers unterbrochen wird, stimmt die PrĂŒfziffer des Journals nicht mit der im Commit-Block ĂŒberein, und die Transaktion wird abgelehnt.Â
Chris Mason , dass es âim Allgemeinen sicherâ wĂ€re, diesen Barrier auch in ext3 zu entfernen, mit möglicher Ausnahme, wenn das Journal zu Ende kommt und von vorne zu schreiben beginnt.Â
Eine weitere Idee zur Leistungssteigerung ist es, Barrier-Operationen, wenn möglich, zu verzögern. Wenn es nicht dringend erforderlich ist, Daten sofort auf die Festplatte zu schreiben, können mehrere Transaktionen im Journal erstellt werden, die dann mit einem Barrier auf die Festplatte geschrieben werden.
Es gibt auch ein gewisses Potenzial zur Verbesserung durch sorgfĂ€ltige Anordnung der Operationen, damit die Barrieren (die normalerweise als Abfragen âalle ausstehenden Operationen auf die Festplatte zurĂŒcksetzenâ implementiert sind) die SchreibvorgĂ€nge von Blöcken, die keine Ordnung erfordern, nicht erzwingen.
Es scheint an der Zeit zu sein, darĂŒber nachzudenken, wie die Kosten fĂŒr Barrieren akzeptabel gestaltet werden können. Ted Tso scheint :
Ich denke, wir sollten Barrieren in ext3/4 einfĂŒhren und dann an der Verringerung der Overheadkosten in ext4/jbd2 arbeiten. Höchstwahrscheinlich arbeiten die ĂŒberwiegende Mehrheit der Systeme nicht in Bedingungen, die denen Ă€hneln, die Chris zur Demonstration des Problems verwendet hat, und die Sicherheit des Dateisystems sollte PrioritĂ€t haben.
Der gesunde Menschenverstand sagt mir, dass dieser Hund jetzt nicht mehr schlĂ€ft und wahrscheinlich eine Weile bellen wird. Das könnte einige Nachbarn beunruhigen, aber es ist besser, als ihm zu erlauben, zu beiĂen.
Interessiert es Sie, sich in diesem Bereich weiterzuentwickeln? Melden Sie sich fĂŒr eine kostenlose Demo-Stunde an und nehmen Sie an der Ăbertragung teil , die von Pawel Wikiryuk â MVNO-Operator, DevOps-Ingenieur, durchgefĂŒhrt wird.
Quelle: habr.com
