Die Variable vfs.vmiodirenable
besitzt
in der Voreinstellung den Wert 1. Die Variable kann auf den Wert
0 (ausgeschaltet) oder 1 (angeschaltet) gesetzt werden. Sie
steuert, wie Verzeichnisse vom System zwischengespeichert
werden. Die meisten Verzeichnisse sind klein und benutzen
nur ein einzelnes Fragment, typischerweise 1 kB,
im Dateisystem. Im Buffer-Cache verbrauchen sie mit
512 Bytes noch weniger Platz. Ist die Variable
ausgeschaltet (auf 0) wird der Buffer-Cache nur
eine limitierte Anzahl Verzeichnisse zwischenspeichern, auch
wenn das System über sehr viel Speicher verfügt.
Ist die Variable aktiviert (auf 1), kann der Buffer-Cache den
VM-Page-Cache benutzen, um Verzeichnisse zwischenzuspeichern.
Der ganze Speicher steht damit zum Zwischenspeichern von
Verzeichnissen zur Verfügung. Der Nachteil bei dieser
Vorgehensweise ist, dass zum Zwischenspeichern eines
Verzeichnisses mindestens eine physikalische Seite im
Speicher, die normalerweise 4 kB groß ist,
anstelle von 512 Bytes gebraucht wird. Wir empfehlen,
diese Option aktiviert zu lassen, wenn Sie Dienste zur
Verfügung stellen, die viele Dateien manipulieren.
Beispiele für solche Dienste sind Web-Caches,
große Mail-Systeme oder Netnews. Die aktivierte
Variable vermindert, trotz des verschwendeten Speichers,
in aller Regel nicht die Leistung des Systems, obwohl Sie
das nachprüfen sollten.
In der Voreinstellung besitzt die Variable
vfs.write_behind
den Wert
1
(aktiviert). Mit dieser Einstellung
schreibt das Dateisystem anfallende vollständige Cluster,
die besonders beim sequentiellen Schreiben großer Dateien
auftreten, direkt auf das Medium aus. Dies verhindert,
dass sich im Buffer-Cache veränderte Puffer
(dirty buffers) ansammeln,
die die I/O-Verarbeitung nicht mehr beschleunigen
würden. Unter bestimmten Umständen blockiert
diese Funktion allerdings Prozesse. Setzen Sie in diesem
Fall die Variable vfs.write_behind
auf
den Wert 0
.
Die Variable vfs.hirunningspace
bestimmt systemweit die Menge ausstehender Schreiboperationen,
die dem Platten-Controller zu jedem beliebigen Zeitpunkt
übergeben werden können. Normalerweise können
Sie den Vorgabewert verwenden. Auf Systemen mit
vielen Platten kann der Wert aber auf 4 bis
5 Megabyte erhöht werden.
Beachten Sie, dass ein zu hoher Wert (größer
als der Schreib-Schwellwert des Buffer-Caches) zu
Leistungverlusten führen kann. Setzen Sie den Wert daher
nicht zu hoch! Hohe Werte können auch Leseoperationen
verzögern, die gleichzeitig mit Schreiboperationen
ausgeführt werden.
Es gibt weitere Variablen, mit denen Sie den Buffer-Cache und den VM-Page-Cache beeinflussen können. Wir raten Ihnen allerdings davon ab, diese Variablen zu verändern, da das VM-System den virtuellen Speicher selbst sehr gut verwaltet.
Die Variable vm.swap_idle_enabled
ist für große Mehrbenutzer-Systeme gedacht, auf
denen sich viele Benutzer an- und abmelden und auf denen
es viele Prozesse im Leerlauf
(idle) gibt. Solche Systeme
fragen kontinuierlich freien Speicher an. Wenn Sie die
Variable vm.swap_idle_enabled
aktivieren,
können Sie die Auslagerungs-Hysterese von Seiten mit
den Variablen vm.swap_idle_threshold1
und
vm.swap_idle_threshold2
einstellen. Die
Schwellwerte beider Variablen geben die Zeit in Sekunden an,
in denen sich ein Prozess im Leerlauf befinden muss. Wenn die
Werte so eingestellt sind, dass Seiten früher als nach dem
normalen Algorithmus ausgelagert werden, verschafft das dem
Auslagerungs-Prozess mehr Luft. Aktivieren Sie diese Funktion
nur, wenn Sie sie wirklich benötigen: Die Speicherseiten
werden eher früher als später ausgelagert. Der
Platz im Swap-Bereich wird dadurch schneller verbraucht und
die Plattenaktivitäten steigen an. Auf kleine Systeme
hat diese Funktion spürbare Auswirkungen. Auf großen
Systemen, die sowieso schon Seiten auslagern müssen,
können ganze Prozesse leichter in den Speicher geladen
oder ausgelagert werden.
In FreeBSD 4.3 wurde versucht, den IDE-Schreib-Zwischenspeicher
abzustellen. Obwohl dies die Bandbreite zum Schreiben auf
IDE-Platten verringerte, wurde es aus Gründen der
Datenkonsistenz als notwenig angesehen. Der Kern des
Problems ist, dass IDE-Platten keine zuverlässige
Aussage über das Ende eines Schreibvorgangs treffen.
Wenn der Schreib-Zwischenspeicher aktiviert ist, werden die Daten
nicht in der Reihenfolge ihres Eintreffens geschrieben. Es kann
sogar passieren, dass das Schreiben mancher Blöcke
im Fall von starker Plattenaktivität auf unbefristete
Zeit verzögert wird. Ein Absturz oder Stromausfall
zu dieser Zeit kann die Dateisysteme erheblich beschädigen.
Wir entschieden uns daher für die sichere Variante
und stellten den Schreib-Zwischenspeicher ab. Leider war
damit auch ein großer Leistungsverlust verbunden, so
dass wir die Variable
nach dem Release wieder aktiviert haben. Sie sollten den
Wert der Variable hw.ata.wc
auf Ihrem
System überprüfen. Wenn der Schreib-Zwischenspeicher
abgestellt ist, können Sie ihn aktivieren, indem Sie die
Variable auf den Wert 1 setzen. Dies muss zum Zeitpunkt
des Systemstarts im Boot-Loader geschehen. Eine Änderung
der Variable, nachdem der Kernel gestartet ist, hat keine
Auswirkungen.
Weitere Informationen finden Sie in ata(4).
Mit der Kerneloption SCSI_DELAY
kann
die Dauer des Systemstarts verringert werden. Der Vorgabewert
ist recht hoch und er verzögert den Systemstart um 15 oder
mehr Sekunden. Normalerweise kann dieser Wert, insbesondere
mit modernen Laufwerken, auf 5 Sekunden heruntergesetzt
werden (durch Setzen der sysctl
-Variable
kern.cam.scsi_delay
). Die Variable
sowie die Kerneloption verwenden für die Zeitangabe
Millisekunden und nicht Sekunden.
Mit tunefs(8) lassen sich Feineinstellungen an Dateisystemen vornehmen. Das Programm hat verschiedene Optionen, von denen hier nur Soft Updates betrachtet werden. Soft Updates werden wie folgt ein- und ausgeschaltet:
#
tunefs -n enable /filesystem
#
tunefs -n disable /filesystem
Ein eingehängtes Dateisystem kann nicht mit tunefs(8) modifiziert werden. Soft Updates werden am besten im Single-User Modus aktiviert, bevor Partitionen eingehangen sind.
Durch Einsatz eines Zwischenspeichers wird die Performance
im Bereich der Metadaten, vorwiegend beim Anlegen und Löschen
von Dateien, gesteigert. Wir empfehlen, Soft Updates auf allen
Dateisystemen zu aktivieren. Allerdings sollten Sie sich über
die zwei Nachteile von Soft Updates bewusst sein:
Erstens garantieren Soft Updates zwar die Konsistenz der Daten
im Fall eines Absturzes, aber es kann leicht passieren, dass
das Dateisystem über mehrere Sekunden oder gar eine Minute
nicht synchronisiert wurde. Im Fall eines Absturzes verlieren
Sie mit Soft Updates unter Umständen mehr Daten als ohne.
Zweitens verzögern Soft Updates die Freigabe von
Datenblöcken. Eine größere Aktualisierung
eines fast vollen Dateisystems, wie dem Root-Dateisystem,
z.B. während eines make installworld
,
kann das Dateisystem vollaufen lassen. Dadurch würde
die Aktualisierung fehlschlagen.
Es gibt zwei klassische Herangehensweisen, wie man die Metadaten des Dateisystems (also Daten über Dateien, wie inode 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, dass sie
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 einer
Datei im Fall eines Absturzes noch nicht den Weg aus dem
„Buffer Cache“ auf die Platte gefunden haben,
kann fsck(8) das Dateisystem reparieren, indem es die
Dateilänge einfach auf 0 setzt. Außerdem
ist die Implementierung einfach und überschaubar. Der
Nachteil ist, dass Änderungen der Metadaten sehr
langsam vor sich gehen. Ein rm -r
beispielsweise fasst 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, dass man nun nicht mehr auf jeden Update
warten muss, Operationen, die zahlreiche Metadaten
ändern, werden also viel schneller. Auch
hier ist die Implementierung sehr einfach und wenig
anfällig für Fehler. Nachteil ist, dass
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 inode 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(8)) 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 dass 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, dass Metadaten zweimal auf die Platte geschrieben werden müssen (einmal in die logging area, einmal an die richtige Stelle), so dass 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, dass im Falle eines Crashes der konsistente Zustand dadurch erzielbar ist, dass 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, dass 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,
dass sie nicht vor ihren Metadaten auf der Platte
sind). Im Fall eines Absturzes 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 bis 60 Sekunden früher
sichergestellt. Der verwendete Algorithmus garantiert
dabei, dass alle tatsächlich benutzten Ressourcen
auch in den entsprechenden Bitmaps (Block- und inode
Tabellen) als belegt markiert sind. Der einzige Fehler, der
auftreten kann, ist, dass Ressourcen noch als
„belegt“ markiert sind, die tatsächlich
„frei“ sind. fsck(8) erkennt dies und
korrigiert diese nicht mehr belegten Ressourcen. 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 muss
später ein fsck(8) nachgeholt werden. Das ist
dann auch die Idee des background fsck:
beim Starten des Systems wird lediglich ein
Schnappschuss des Filesystems
gemacht, mit dem 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 Ressourcen
freizugeben. (Dateisysteme ohne Soft
Updates benötigen natürlich immer noch
den üblichen (Vordergrund-)fsck
,
bevor sie eingebunden werden können.)
Der Vorteil ist, dass 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 muss). 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
muss 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.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.