Der folgende Abschnitt beschreibt die verschiedenen Methoden zur Feinabstimmung der Laufwerke. Oft sind mechanische Teile in Laufwerken, wie SCSI-Laufwerke, verbaut. Diese können einen Flaschenhals bei der Gesamtleistung des Systems darstellen. Sie können zwar auch ein Laufwerk ohne mechanische Teile einbauen, wie z.B. ein Solid-State-Drive, aber Laufwerke mit mechanischen Teilen werden auch in naher Zukunft nicht vom Markt verschwinden. Bei der Feinabstimmung ist es ratsam, die Funktionen von iostat(8) zu verwenden, um verschiedene Änderungen zu testen und um nützliche IO-Informationen des Systems zu erhalten.
Die sysctl(8)-Variable
vfs.vmiodirenable
besitzt in der
Voreinstellung den Wert 1
. Die Variable
kann auf den Wert 0
(deaktiviert) oder
1
(aktiviert) 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 und 512 Bytes im Buffer-Cache. Ist
die Variable deaktiviert, wird der Buffer-Cache nur
eine limitierte Anzahl Verzeichnisse zwischenspeichern, auch
wenn das System über sehr viel Speicher verfügt.
Ist die Variable aktiviert, 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. Es
wird empfohlen, 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
sysctl(8)-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 sysctl(8)-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. Ein zu hoher Wert (größer als der
Schreib-Schwellwert des Buffer-Caches) kann zu
Leistungsverlusten führen. 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 sysctl(8)-Variablen, mit denen Sie den Buffer-Cache und den VM-Page-Cache beeinflussen können. Es wird nicht empfohlen, diese Variablen zu verändern, da das VM-System den virtuellen Speicher selbst sehr gut verwaltet.
Die sysctl(8)-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 kleinen
Systemen 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.
Obwohl das Abstellen des
IDE-Schreib-Zwischenspeichers die
Bandbreite zum Schreiben auf die
IDE-Festplatte verringert, kann es aus
Gründen der Datenkonsistenz als notwendig angesehen werden.
Das Problem 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. Sie sollten den Wert der
sysctl(8)-Variable hw.ata.wc
auf dem
System überprüfen. Wenn der Schreib-Zwischenspeicher
abgestellt ist, können Sie ihn beim Systemstart aktivieren,
indem Sie die Variable in
/boot/loader.conf
auf den Wert
1
setzen.
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, mit
der sysctl(8)-Variable
kern.cam.scsi_delay
auf
5
Sekunden heruntergesetzt werden. 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. 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. Es wird empfohlen, Soft Updates auf
allen UFS-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
passieren, dass das Dateisystem über mehrere Sekunden oder gar
eine Minute nicht synchronisiert wurde. Nicht geschriebene
Daten gehen dann vielleicht verloren. 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.
Bei einem Metadaten-Update werden die Inodes und Verzeichniseinträge aktualisiert auf die Platte zurückgeschrieben. Es gibt zwei klassische Ansätze, um die Metadaten des Dateisystems auf die Platte zu schreiben.
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
später asynchron 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 mit tar -x
.
Der zweite Ansatz sind asynchrone Metadaten-Updates.
Das ist der Standard, wenn
UFS-Dateisysteme mit
mount -o async
eingehängt werden. 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-Schalters), 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(8)
mehr implementieren, das diesen Zustand
wieder reparieren kann, da die dazu nötigen
Informationen einfach auf der Platte fehlen. Wenn ein
Dateisystem irreparabel beschädigt wurde, hat man nur noch
die Möglichkeit es neu zu erzeugen und die Daten vom Backup
zurückspielen.
Der Ausweg aus diesem Dilemma ist ein dirty region logging, was auch als Journalling bezeichnet 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 Absturzes 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 Dateisystems
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(8) 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(8), bevor sie
eingebunden werden können.
Der Vorteil ist, dass die Metadaten-Operationen beinahe so schnell ablaufen wie im asynchronen Fall, also auch schneller als beim logging, das die Metadaten immer zweimal schreiben muss. Als Nachteil stehen dem die Komplexität des Codes, ein erhöhter Speicherverbrauch und einige spezielle Eigenheiten entgegen. Nach einem Absturz ist ein etwas „älterer“ Stand auf der Platte – statt einer leeren, aber bereits angelegten Datei, wie nach einem herkömmlichen fsck(8) 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(1) 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 installiert 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>.