Add the translation for the details about soft updates (rev 1.33 of
the English version). Submitted by: Matthias Schuendehuette <msch@snafu.de> Reviewed by: Martin Heinen <martin@sumuk.de>
This commit is contained in:
Joerg Wunsch
parent
cff9e5728e
commit
9b1303747c
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=12066
1 changed files with 171 additions and 0 deletions
|
|
@ -943,6 +943,177 @@ kern.maxfiles: 2088 -> 5000</screen>
|
|||
z.B. während eines <command>make installworld</command>,
|
||||
kann das Dateisystem vollaufen lassen. Dadurch würde
|
||||
die Aktualisierung fehlschlagen.</para>
|
||||
|
||||
<sect3>
|
||||
<title>Details über Soft Updates</title>
|
||||
|
||||
<indexterm><primary>Soft Updates (Details)</primary></indexterm>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<para>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
|
||||
<emphasis>Inhalt</emphasis> der Dateien wurde im
|
||||
<quote>Buffer Cache</quote> 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 <quote>Buffer Cache</quote> 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 <command>rm -r</command>
|
||||
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 (<command>tar -x</command>).</para>
|
||||
|
||||
<para>Der zweite Fall sind asynchrone Metadaten-Updates. Das
|
||||
ist z. B. der Standard bei Linux/ext2fs oder die Variante
|
||||
<command>mount -o async</command> für *BSD UFS. Man
|
||||
schickt die Updates der Metadaten einfach auch noch
|
||||
über den <quote>Buffer Cache</quote>, 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 <command>fsck</command>
|
||||
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 (<command>newfs</command>) und die Daten
|
||||
vom Backup zurückspielen.
|
||||
</para>
|
||||
|
||||
<para>Der historische Ausweg aus diesem Dilemma war ein
|
||||
<emphasis>dirty region logging</emphasis> (auch als
|
||||
<emphasis>Journalling</emphasis> 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
|
||||
<emphasis>logging area</emphasis>. Von da aus werden sie
|
||||
dann asynchron auf ihre eigentlichen Bereiche verteilt. Da
|
||||
die <emphasis>logging area</emphasis> 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
|
||||
<emphasis>logging area</emphasis>, einmal an die richtige
|
||||
Stelle), so daß das im Falle regulärer
|
||||
Arbeit (also keine gehäuften Metadatenoperationen) eine
|
||||
<quote>Pessimisierung</quote> 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 <emphasis>dirty region
|
||||
log</emphasis> entweder zu Ende ausgeführt oder
|
||||
komplett verworfen werden, wodurch das Dateisystem schnell
|
||||
wieder zur Verfügung steht.
|
||||
</para>
|
||||
|
||||
<para>Die Lösung von Kirk McKusick (dem Schöpfer von
|
||||
Berkeley FFS) waren <emphasis>Soft Updates</emphasis>: die
|
||||
notwendigen Updates der Metadaten werden im Speicher
|
||||
gehalten und dann sortiert auf die Platte geschrieben
|
||||
(<quote>ordered metadata updates</quote>). 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
|
||||
<quote>einholen</quote>. 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 <quote>log
|
||||
rewind</quote>: 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
|
||||
<quote>belegt</quote> markiert sind, die tatsächlich
|
||||
<quote>frei</quote> 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
|
||||
<command>mount -f</command> zwangsweise eingebunden werden.
|
||||
Um noch allozierte Ressourcen freizugeben muß
|
||||
später ein &man.fsck.8; nachgeholt werden. Das ist
|
||||
dann auch die Idee des <emphasis>background fsck</emphasis>:
|
||||
beim Starten des Systems wird lediglich ein
|
||||
<emphasis>Schnappschuß</emphasis> des Filesystems
|
||||
gemacht, mit dem &man.fsck.8; dann später arbeiten
|
||||
kann. Alle Dateisysteme dürfen <quote>unsauber</quote>
|
||||
eingebunden werden und das System kann sofort in den
|
||||
Multiuser-Modus gehen. Danach wird ein
|
||||
Hintergrund-<command>fsck</command> für die
|
||||
Dateisysteme gestartet, die dies benötigen, um
|
||||
möglicherweise irrtümlich belegte Resourcen
|
||||
freizugeben. (Dateisysteme ohne <emphasis>Soft
|
||||
Updates</emphasis> benötigen natürlich immer noch
|
||||
den üblichen (Vordergrund-)<command>fsck</command>,
|
||||
bevor sie eingebunden werden können.)</para>
|
||||
|
||||
<para>Der Vorteil ist, daß die Metadaten-Operationen
|
||||
beinahe so schnell ablaufen wie im asynchronen Fall (also
|
||||
durchaus auch schneller als beim <quote>logging</quote>, 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 <quote>Eigenheiten</quote>
|
||||
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
|
||||
<command>fsck</command> Lauf) ist auf einem Dateisystem mit
|
||||
<emphasis>Soft Updates</emphasis> 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 <command>rm -r</command>
|
||||
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.</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue