vfs.vmiodirenable
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.
vfs.write_behind
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.
vfs.hirunningspace
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.
vm.swap_idle_enabled
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.
hw.ata.wc
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).
kern.cam.scsi_delay
)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.
Zurück | Zum Anfang | Weiter |
Einstellungen mit sysctl | Nach oben | Einstellungen von Kernel Limits |
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>.