On Sun, Feb 16, 2003 at 07:51:34PM +0100, Thorsten von Plotho-Kettner wrote:

Journaling funktioniert so: Jeder Schreibzugriff auf das Dateisystem wird zuerst im Journal bzw. Transaktionslog vorgemerkt, wenn die Daten später wirklich ins Dateisystem eingetragen wurden, wird der entsprechende Eintrag im Journal als erledigt markiert.

Puristen unterscheiden drei Arten von Journal: Metadaten-Log und Daten-Log sowie logfreie ordered-writes. Bei einem Daten-Log funktioniert das so, wie Du es schreibst: Alle Writes gehen zunächst in das Journal, und danach wird das Journal abgearbeitet und in das Dateisystem comitted. ext3 kann so arbeiten, und das inzwischen nicht mehr so richtig unterstützte BSD LFS arbeitet zum Beispiel NUR mit einem Daten-Log und hat gar kein normales Dateisystem-Area im engeren Sinne mehr (das hat in bestimmten Bereichen Vorteile, ist aber so spezialisiert, dass es im allgemeinen Fall schlechter performt). Bei einem Metadaten-Log werden die Datenblöcke selber nicht geloggt, sondern nur die Änderungen an Verwaltungsstrukturen (Inode- und Datenzeiger-Blöcke). Dies ist, was Reiserfs und XFS machen, und für ext3 gibt es ebenfalls einen solchen Modus. Bei ordered writes existiert kein Log im engeren Sinne, sondern die Schreiboperationen im Cache des betriebssystems werden in so einer Reihenfolge ausführt ("baumaufwärts" in einer Datei und im Dateisystem), daß das Dateisystem immer in einem konsistenten oder wiederherstellbaren Zustand ist. BSD ufs macht das so, und kann obendrein ein nicht gechecktes Dateisystem mounten und dann im Hintergrund recovern ("background fsck"). Diese Form der Organisation kommt ohne ein explizites Log aus, hat aber für alle praktischen Zwecke denselben Effekt.

separater Kernelpatch vor. ReiserFS kann bei sehr vielen kleinen Dateien viel Platz sparen, da es nicht für jede einzelne Datei eine ganze Anzahl Blöcke belegt.

Reiserfs und XFS organisieren Verzeichnisse außerdem in Baumstrukturen und nicht als lineare Listen. Beide Dateisysteme sind daher bei Verzeichnissen mit vielen Einträgen (mehr als 1000 Einträge pro Verzeichnis) sehr viel schneller und skalieren sich leicht bis zu Verzeichnisgrößen mit 10E6-10E9 Einträgen.

* XFS/Linux http://oss.sgi.com/projects/xfs/: Port des bewährten Dateisystem XFS von IRIX auf Linux. XFS bietet alles was das Herz begehrt (inklusive Quota und ACL) und ist auf IRIX seit 1994 im Einsatz. Das Projekt liegt als externer Kernelpatch vor, der Linux Port ist noch recht jung, über seine Stabilität kann man daher noch keine definitiven Aussagen machen.

In Suse Linux ist es ab Werk enthalten. XFS in Irix hat außerdem eine ganze Reihe von weiteren Eigenschaften, die es sehr interessant für große Datei- und Dateisystemstrukturen machen. Ich weiß nicht, wieviel davon auf Linux portiert worden ist. XFS mapped Plattenblöcke für Dateien nicht in dem Moment auf eine physikalische Position auf der Platte, in dem der Platz benötigt wird, sondern erst in dem Moment, in dem die Datei auf das Medium geflushed wird. Das ist bei kleinen Dateien der Moment, in dem die Datei geschlossen wird. Der Block Allocator im Dateisystem hat so mehr Informationen als bei herkömmlichen Dateisystemen und könnte die Datei im Grunde genommen unfragmentiert allozieren, wenn es denn überhaupt noch eine Allokation gibt, die groß genug für die Datei ist. XFS entnimmt freien Speicher nicht aus einer großen Bitmap mit einem einzigen Lock, sondern unterteilt die Platte in jeweils Gigabyte große Allocation Regions. Während bei anderen Dateisystemen also jeweils nur eine Datei zur Zeit wachsen kann, können bei XFS Dateien in unterschiedlichen Allocation Regions parallel wachsen. Dies ist für Dateisysteme, in denen eine große Anzahl kleiner Dateien gleichzeitig erzeugt oder vergrößert wird, von großem Vorteil. In Unix garantiert das Betriebssystem, daß jeder write in eine Datei atomar ist, auch wenn er über mehr als einen Block geht. Wenn ich also 10 Blöcke ab Position 102400 in die Datei schreibe, dann kann ein Read nicht 5 geänderte und 5 ungeänderte Blöcke ab dieser Position vorfinden, sondern er findet entweder 10 geänderte oder 10 alte Blöcke vor. Unix implementiert das mit einem Lock in der Inode der Datei, d.h. es kann überhaupt immer nur ein Write zur Zeit aktiv sein, und wenn dies der Fall ist, dann kann kein Read auf die Datei aktiv sein. In einer großen Datenbankdatei, an der an vielen Stellen zur Zeit gleichzeitig geändert werden muß, ist dies ein Bottleneck und verlangsamt den Zugriff. XFS erzeugt an der Inode der Datei stattdessen eine Liste von Writes (eigentlich einen Baum, alles in XFS sind Bäume), mit Startadresse und Länge. XFS erlaubt jetzt beliebig viele nichtüberlappende Writes zu, und verzögert nur die Reads, die Bereiche berühren, die gerade geschrieben werden. Auf diese Weise können sehr viele parallele Schreibzugriffe auf eine einzelne Datei stattfinden. Für eine Technologie von 1994 ist XFS heute noch allen anderen Dateisystemen weit voraus.

* JFS http://oss.software.ibm.com/developerworks/opensource/jfs/: Port des Dateisystems JFS von OS/2 auf Linux. Auf Grund seines Entwicklungsstandes nur mäßig interessant.

JFS und LVM sind Technologien, die aus der Welt von AIX, nicht von OS/2, stammen. HPFS von OS/2 ist etwas anderes.

Registrierter Linuxuser #275535

Kristian (Registrierter Linuxuser #70337, Registrierter Slashdotuser #824 :-) -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG