From 9b1303747c2b1308ccf3c36d208f007562185e56 Mon Sep 17 00:00:00 2001 From: Joerg Wunsch Date: Sat, 2 Feb 2002 21:31:49 +0000 Subject: [PATCH] Add the translation for the details about soft updates (rev 1.33 of the English version). Submitted by: Matthias Schuendehuette Reviewed by: Martin Heinen --- .../books/handbook/config/chapter.sgml | 171 ++++++++++++++++++ 1 file changed, 171 insertions(+) diff --git a/de_DE.ISO8859-1/books/handbook/config/chapter.sgml b/de_DE.ISO8859-1/books/handbook/config/chapter.sgml index d3827a8e23..0f09462a84 100644 --- a/de_DE.ISO8859-1/books/handbook/config/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/config/chapter.sgml @@ -943,6 +943,177 @@ kern.maxfiles: 2088 -> 5000 z.B. während eines make installworld, kann das Dateisystem vollaufen lassen. Dadurch würde die Aktualisierung fehlschlagen. + + + Details über Soft Updates + + Soft Updates (Details) + + Es gibt zwei klassische Herangehensweisen, wie + man die Metadaten des Dateisystems (also Daten + über Dateien, wie i-node Bereiche oder Verzeichniseinträge) + aktualisiert auf die Platte zurückschreibt: + + Das historisch übliche Verfahren waren synchrone + Updates der Metadaten, d. h. wenn eine Änderung an + einem Verzeichnis nötig war, wurde anschließend + gewartet, bis diese Änderung tatsächlich auf die + Platte zurückgeschrieben worden war. Der + Inhalt der Dateien wurde im + Buffer Cache zwischengespeichert und + asynchron irgendwann später auf die Platte geschrieben. + Der Vorteil dieser Implementierung ist, daß sie sehr + sicher funktioniert. Wenn während eines Updates ein + Ausfall erfolgt, haben die Metadaten immer einen + konsistenten Zustand. Eine Datei ist entweder komplett + angelegt oder gar nicht. Wenn die Datenblöcke der + Datei den Weg aus dem Buffer Cache noch nicht + auf die Platte gefunden haben, dann kann &man.fsck.8; dies + feststellen und das Dateisystem reparieren (die + Dateilänge wird dann auf 0 gesetzt). Außerdem + ist die Implementierung einfach und überschaubar. Der + Nachteil ist, daß Änderungen der Metadaten sehr + langsam vor sich gehen. Ein rm -r + beispielsweise faßt alle Dateien eines Verzeichnisses + der Reihe nach an, aber jede dieser Änderungen am + Verzeichnis (Löschen einer Datei) wird einzeln synchron + auf die Platte geschrieben. Gleiches beim Auspacken + großer Hierarchien (tar -x). + + Der zweite Fall sind asynchrone Metadaten-Updates. Das + ist z. B. der Standard bei Linux/ext2fs oder die Variante + mount -o async für *BSD UFS. Man + schickt die Updates der Metadaten einfach auch noch + über den Buffer Cache, sie werden also + zwischen die Updates der normalen Daten eingeschoben. + Vorteil ist, daß man nun nicht mehr auf jeden Update + warten muß, Operationen mit vielen + Metadatenänderungen werden also viel schneller. Auch + hier ist die Implementierung sehr einfach und wenig + anfällig für Fehler. Nachteil ist, daß + keinerlei Konsistenz des Dateisystems mehr gesichert ist. + Wenn mitten in einer Operation, die viele Metadaten + ändert, ein Ausfall erfolgt (Stromausfall, drücken + des Reset-Tasters), dann ist das Dateisystem + anschließend in einem unbestimmten Zustand. Niemand + kann genau sagen, was noch geschrieben worden ist und was + nicht mehr; die Datenblöcke einer Datei können + schon auf der Platte stehen, während die i-node Tabelle + oder das zugehörige Verzeichnis nicht mehr aktualisiert + worden ist. Man kann praktisch kein fsck + mehr implementieren, das diesen Zustand + wieder reparieren kann, da die dazu nötigen + Informationen einfach auf der Platte fehlen. Wenn ein + Dateisystem derart beschädigt worden ist, kann man es + nur neu erzeugen (newfs) und die Daten + vom Backup zurückspielen. + + + Der historische Ausweg aus diesem Dilemma war ein + dirty region logging (auch als + Journalling bezeichnet, wenngleich + dieser Begriff nicht immer gleich benutzt und manchmal auch + für andere Formen von Transaktionsprotokollen gebraucht + wird). Man schreibt die Metadaten-Updates zwar synchron, + aber nur in einen kleinen Plattenbereich, die + logging area. Von da aus werden sie + dann asynchron auf ihre eigentlichen Bereiche verteilt. Da + die logging area ein kleines + zusammenhängendes Stückchen ist, haben die + Schreibköpfe der Platte bei massiven Operationen auf + Metadaten keine allzu großen Wege zurückzulegen, + so daß alles ein ganzes Stück schneller geht als + bei klassischen synchronen Updates. Die Komplexität + der Implementierung hält sich ebenfalls in Grenzen, + somit auch die Anfälligkeit für Fehler. Als + Nachteil ergibt sich, daß Metadaten zweimal auf die + Platte geschrieben werden müssen (einmal in die + logging area, einmal an die richtige + Stelle), so daß das im Falle regulärer + Arbeit (also keine gehäuften Metadatenoperationen) eine + Pessimisierung des Falls der synchronen + Updates eintritt, es wird alles langsamer. Dafür hat man + als Vorteil, daß im Falle eines Crashes der + konsistente Zustand dadurch erzielbar ist, daß die + angefangenen Operationen aus dem dirty region + log entweder zu Ende ausgeführt oder + komplett verworfen werden, wodurch das Dateisystem schnell + wieder zur Verfügung steht. + + + Die Lösung von Kirk McKusick (dem Schöpfer von + Berkeley FFS) waren Soft Updates: die + notwendigen Updates der Metadaten werden im Speicher + gehalten und dann sortiert auf die Platte geschrieben + (ordered metadata updates). Dadurch hat man + den Effekt, daß im Falle massiver + Metadaten-Änderungen spätere Operationen die + vorhergehenden, noch nicht auf die Platte geschriebenen + Updates desselben Elements im Speicher + einholen. Alle Operationen, auf ein + Verzeichnis beispielsweise, werden also in der Regel noch im + Speicher abgewickelt, bevor der Update überhaupt auf + die Platte geschrieben wird (die dazugehörigen + Datenblöcke werden natürlich auch so sortiert, + daß sie nicht vor ihren Metadaten auf der Platte + sind). Im Crashfall hat man ein implizites log + rewind: alle Operationen, die noch nicht den Weg auf + die Platte gefunden haben, sehen danach so aus, als + hätten sie nie stattgefunden. Man hat so also den + konsistenten Zustand von ca. 30 -- 60 Sekunden früher + sichergestellt. Der verwendete Algorithmus garantiert + dabei, daß alle tatsächlich benutzten Ressourcen + auch in den entsprechenden Bitmaps (Block- und i-node + Tabellen) als belegt markiert sind. Der einzige Fehler, der + auftreten kann, ist, daß Ressourcen noch als + belegt markiert sind, die tatsächlich + frei sind. &man.fsck.8; erkennt dies und + korrigiert diese nicht mehr belegten Resourcen. Die + Notwendigkeit eines Dateisystem-Checks darf aus diesem + Grunde auch ignoriert und das Dateisystem mittels + mount -f zwangsweise eingebunden werden. + Um noch allozierte Ressourcen freizugeben muß + später ein &man.fsck.8; nachgeholt werden. Das ist + dann auch die Idee des background fsck: + beim Starten des Systems wird lediglich ein + Schnappschuß des Filesystems + gemacht, mit dem &man.fsck.8; dann später arbeiten + kann. Alle Dateisysteme dürfen unsauber + eingebunden werden und das System kann sofort in den + Multiuser-Modus gehen. Danach wird ein + Hintergrund-fsck für die + Dateisysteme gestartet, die dies benötigen, um + möglicherweise irrtümlich belegte Resourcen + freizugeben. (Dateisysteme ohne Soft + Updates benötigen natürlich immer noch + den üblichen (Vordergrund-)fsck, + bevor sie eingebunden werden können.) + + Der Vorteil ist, daß die Metadaten-Operationen + beinahe so schnell ablaufen wie im asynchronen Fall (also + durchaus auch schneller als beim logging, das + ja die Metadaten immer zweimal schreiben muß). Als + Nachteil stehen dem die Komplexität des Codes (mit + einer erhöhten Fehlerwahrscheinlichkeit in einem + bezüglich Datenverlust hoch sensiblen Bereich) und ein + erhöhter Speicherverbrauch entgegen. Außerdem + muß man sich an einige Eigenheiten + gewöhnen: Nach einem Absturz ist ein etwas älterer + Stand auf der Platte - statt einer leeren, aber bereits + angelegten Datei (wie nach einem herkömmlichen + fsck Lauf) ist auf einem Dateisystem mit + Soft Updates keine Spur der + entsprechenden Datei mehr zu sehen, da weder die Metadaten + noch der Dateiinhalt je auf die Platte geschrieben wurden. + Weiterhin kann der Platz nach einem rm -r + nicht sofort wieder als verfügbar markiert werden, + sondern erst dann, wenn der Update auch auf die Platte + vermittelt worden ist. Dies kann besonders dann Probleme + bereiten, wenn große Datenmengen in einem Dateisystem + ersetzt werden, das nicht genügend Platz hat, um alle + Dateien zweimal unterzubringen. + +