In ReiserFS werden alle Daten in einer Struktur namens B^*-balanced tree organisiert. Die Baumstruktur trägt zur besseren Festplattenspeicherverwaltung bei, da kleine Dateien direkt in den Blättern des B^*trees gespeichert werden können, statt sie an anderer Stelle zu speichern und einfach den Zeiger auf den tatsächlichen Ort zu verwalten. Zusätzlich dazu wird der Speicher nicht in Einheiten von 1 oder 4 kB zugewiesen, sondern in exakt der benötigten Einheit. Ein weiterer Vorteil liegt in der dynamischen Vergabe von Inodes. Dies verschafft dem Dateisystem eine größere Flexibilität gegenüber herkömmlichen Dateisystemen, wie zum Beispiel Ext2, wo die Inode-Dichte zum Zeitpunkt der Erstellung des Dateisystems angegeben werden muss.

Bei kleinen Dateien werden sowohl die Dateidaten als auch die „stat_data“ (Inode)-Informationen häufig nebeneinander gespeichert. Ein einziger Festplattenzugriff reicht somit, um Sie mit allen benötigten Informationen zu versorgen.

Durch den Einsatz eines Journals zur Nachverfolgung kürzlicher Metadatenänderungen reduziert sich die Dateisystemüberprüfung sogar für große Dateisysteme auf wenige Sekunden.

ReiserFS unterstützt auch die Modi Data-Journaling und „order data“. Die Arbeitsweise ähnelt der unter Abschnitt 34.2.3, „Ext3“ für Ext3 beschriebenen. Der Standardmodus data=ordered gewährleistet die Integrität der Daten und Metadaten, setzt Journaling jedoch nur für Metadaten ein.

Als wahrer Oldtimer erfuhr Ext2 viele Verbesserungen und wurde ausführlich getestet. Daher wohl auch sein Ruf als absolut stabiles Dateisystem. Im Falle eines Systemausfalls, bei dem das Dateisystem nicht sauber aus dem Verzeichnisbaum ausgehängt werden konnte, startet e2fsck eine Analyse der Dateisystemdaten. Metadaten werden in einen konsistenten Zustand gebracht und momentan nicht zuzuordnende Dateien oder Datenblöcke werden in ein gesondertes Verzeichnis (lost+found) geschrieben. Im Gegensatz zu (den meisten) Journaling File Systemen analysiert e2fsck das gesamte Dateisystem und nicht nur die kürzlich veränderten Metadatenbits. Dies dauert bedeutend länger als die Überprüfung der Protokolldaten eines Journaling File Systems. Je nach Größe des Dateisystems kann dies eine halbe Stunde und mehr in Anspruch nehmen. Deshalb werden Sie Ext2 für keinen Server wählen, der hochverfügbar sein muss. Da Ext2 jedoch kein Journal pflegen muss und bedeutend weniger Speicher verbraucht, ist es manchmal schneller als andere Dateisysteme.

Basierend auf dem starken Fundament Ext2 konnte sich Ext3 zu einem gefeierten Dateisystem der nächsten Generation entwickeln. Seine Zuverlässigkeit und Stabilität wurden geschickt mit den Vorzügen eines Journaling File Systems verbunden.

Da Ext3 auf dem Ext2-Code beruht und sowohl sein platteneigenes Format als auch sein Metadatenformat teilt, sind Upgrades von Ext2 auf Ext3 sehr unkompliziert. Anders als beim eventuell sehr mühsamen Umstieg auf andere Journaling File Systeme wie zum Beispiel ReiserFS, JFS, oder XFS (Sie müssen Sicherungskopien des gesamten Dateisystems erstellen und dieses anschließend von Grund auf neu erstellen) ist ein Umstieg auf Ext3 eine Angelegenheit von Minuten. Zugleich ist er sehr sicher, da die Wiederherstellung eines gesamten Dateisystems von Grund auf nicht immer fehlerlos vonstatten geht. Betrachtet man die Anzahl der vorhandenen Ext2-Systeme, die auf ein Upgrade auf ein Journaling File System warten, kann man sich leicht die Bedeutung von Ext3 für viele Systemadministratoren ausmalen. Ein Downgrade von Ext3 auf Ext2 ist genauso leicht wie das Upgrade. Führen Sie einfach einen sauberen Unmount des Ext3-Dateisystems durch und mounten Sie es als ein Ext2-Dateisystem.

Einige andere Journaling File Systeme folgen beim Journaling dem „metadata-only“-Ansatz. Das heißt, Ihre Metadaten bleiben in einem konsistenten Zustand; dies kann jedoch nicht automatisch für die Dateisystemdaten selbst garantiert werden. Ext3 ist in der Lage, sich sowohl um die Metadaten als auch die Daten selbst zu kümmern. Bis zu welchem Grade sich Ext3 um Daten und Metadaten kümmert, ist individuell einstellbar. Den höchsten Grad an Sicherheit (d.h. Datenintegrität) erreicht man durch den Start von Ext3 im data=journal-Modus; dies jedoch kann das System verlangsamen, da sowohl Metadaten als auch Daten selbst im Journal erfasst werden. Ein relativ neuer Ansatz besteht in der Verwendung des data=ordered-Modus, der sowohl die Daten- als auch die Metadatenintegrität gewährleistet, jedoch das Journaling nur für Metadaten verwendet. Der Dateisystemtreiber sammelt alle Datenblöcke, die zu einem Metadaten-Update gehören. Diese Datenblöcke werden auf die Platte geschrieben, bevor die Metadaten aktualisiert sind. Somit erreicht man Metadaten- und Datenkonsistenz ohne Leistungsverlust. Eine dritte Verwendungsart ist data=writeback. Hierbei können Daten in das Hauptdateisystem geschrieben werden, nachdem ihre Metadaten an das Journal übergeben wurden. Diese Option ist nach Meinung vieler aus Performancegründen die beste Einstellung. Jedoch kann es bei dieser Option passieren, dass alte Daten nach einem Absturz und einer Wiederherstellung in Dateien auftauchen, obwohl die interne Dateisystemintegrität gewahrt wird. Sofern nicht anders angegeben, wird Ext3 mit der Standardeinstellung data=ordered gestartet.

Rufen Sie tune2fs -j als Benutzer root auf. Hierdurch wird ein Ext3-Journal mit Standardparametern angelegt. Möchten Sie selbst festlegen, wie groß und auf welchem Gerät das Journal angelegt werden soll, rufen Sie stattdessen tune2fs -J mit den beiden Journal-Optionen size= und device= auf. Mehr zu tune2fs entnehmen Sie der Manualpage tune2fs(8).

Damit das Ext3-Dateisystem auch als solches erkannt wird, öffnen Sie die Datei /etc/fstab und ändern Sie den Dateisystemtyp der betroffenen Partition von ext2 in ext3. Nach dem nächsten Neustart des Systems ist Ihre Änderung wirksam.

Wenn Sie von einem Root-Dateisystem booten möchten, das eine Ext3-Partition darstellt, so ist es zusätzlich nötig, die Module ext3 und jbd in die initrd zu integrieren. Tragen Sie die beiden Module hierzu in der Datei /etc/sysconfig/kernel bei den INITRD_MODULES zusätzlich ein, und rufen Sie den Befehl mkinitrd auf.

Beim Entwurf von Reiser4 legten die Entwickler besonderen Wert auf die Implementierung von sicherheitsrelevanten Eigenschaften. Daher enthält Reiser4 eine Reihe von speziellen Sicherheits-Plugins. Das wichtigste Plugin führt das Konzept von Datei-„Items“ ein. Zur Zeit wird die Dateizugriffskontrolle pro Datei definiert. Bei einer großen Datei, welche für verschiedene Benutzer, Gruppen oder Anwendungen relevante Information enthält, müssen die Zugriffsrechte ziemlich breit gesetzt werden, um alle betroffenen Parteien miteinzubeziehen. Bei Reiser4 können diese Dateien in kleinere Bestandteile aufgeteilt werden (die „Items“). Zugriffsrechte können dann für jedes Item und jeden Benutzer gesondert gesetzt werden, wodurch eine viel präzisere Regelung der Dateisicherheit möglich ist. Ein ideales Beispiel hierzu ist /etc/passwd. Bis jetzt konnte nur root die Datei lesen und schreiben, während Nicht-root-Benutzer lediglich Lesezugriff auf diese Datei hatten. Mit Hilfe des Item-Konzeptes in Reiser4 kann diese Datei nun in verschiedene Items aufgeteilt werden (ein Item pro Benutzer). Somit können Benutzer oder Anwendungen ihre eigenen Daten ändern, ohne jedoch Zugriff auf die Daten anderer zu haben. Dieses Konzept trägt sowohl zur Sicherheit als auch zur Flexibilität bei.

Viele Dateisystemfunktionen und externe Funktionen, die normalerweise von einem Dateisystem verwendet werden, sind in Reiser4 in der Form von Plugins realisiert. Diese Plugins können dem Basissystem sehr leicht hinzugefügt werden. Dadurch ist es nicht mehr nötig, den Kernel neu zu kompilieren oder die Festplatte neu zu formatieren, um dem Dateisystem neue Funktionalitäten hinzuzufügen.

Wie XFS unterstützt auch Reiser4 „Delayed Allocation“. Siehe Abschnitt 34.2.7, „XFS“. Diese Technik ermöglicht eine besseres Layout des Dateisystems.

JFS folgt einem „metadata only“-Ansatz. Anstelle einer ausführlichen Überprüfung werden lediglich Metadatenänderungen überprüft, die durch kürzliche Dateisystemaktivitäten hervorgerufen wurden. Dies spart enorm viel Zeit bei der Wiederherstellung. Zeitgleiche Aktivitäten, die mehrere Protokolleinträge erfordern, können in einem Gruppen-Commit zusammengefasst werden, wobei der Leistungsverlust des Dateisystems durch mehrfachen Schreibvorgang stark verringert wird.

JFS benutzt zwei unterschiedliche Verzeichnisstrukturen. Bei kleinen Verzeichnissen erlaubt es die direkte Speicherung des Verzeichnisinhaltes in seinem Inode. Für größere Verzeichnisse werden B⁺trees verwendet, welche die Verzeichnisverwaltung erheblich erleichtern.

Unter Ext2 müssen Sie die Inode-Dichte (von Verwaltungsinformationen belegter Speicher) vorab angeben. Dadurch wird die maximale Anzahl von Dateien oder Verzeichnissen Ihres Dateisystems limitiert. JFS erspart Ihnen diese Überlegungen — es weist Inode-Speicher dynamisch zu und stellt ihn bei Nichtbedarf wieder zur Verfügung.

Zum Erstellungszeitpunkt eines XFS-Dateisystems wird das dem Dateisystem zugrunde liegende Block-Device in acht oder mehr lineare Bereiche gleicher Größe unterteilt. Diese werden als „Allocation Groups“ bezeichnet. Jede Allocation Group verwaltet Inodes und freien Speicher selbst. Allocation Groups können praktisch als „Dateisysteme im Dateisystem“ betrachtet werden. Da Allocation Groups relativ autonom sind, kann der Kernel gleichzeitig mehrere von ihnen adressieren. Hier liegt der Schlüssel zur hohen Skalierbarkeit von XFS. Das Konzept der autonomen Allocation Groups kommt natürlicherweise den Anforderungen von Multiprozessorsystemen entgegen.

Freier Speicher und Inodes werden von B⁺ trees innerhalb der Allocation Groups verwaltet. Der Einsatz von B⁺trees trägt zu einem Großteil zur Leistung und Skalierbarkeit von XFS bei. XFS benutzt „Delayed Allocation“. XFS führt die Speicherzuweisung (engl. Allocation) in zwei aufeinander folgenden Schritten durch. Eine noch ausstehende Transaktion wird zunächst in RAM gespeichert und der entsprechende Speicherplatz reserviert. XFS entscheidet noch nicht, wo genau (d.h. in welchen Dateisystemblöcken) die Daten gespeichert werden. Diese Entscheidung wird bis zum letztmöglichen Moment hinausgezögert. Einige kurzlebige, temporäre Daten werden somit niemals auf Platte gespeichert, da sie zum Zeitpunkt der Entscheidung über ihren Speicherort durch XFS bereits obsolet sind. So erhöht XFS die Leistung und verringert die Dateisystemfragmentation. Da allerdings eine verzögerte Zuordnung weniger Schreibvorgänge als in anderen Dateisystemen zur Folge hat, ist es wahrscheinlich, dass der Datenverlust nach einem Absturz während eines Schreibvorgangs größer ist.

Vor dem Schreiben der Daten in das Dateisystem reserviert XFS den benötigten Speicherplatz für eine Datei (engl. preallocate). Somit wird die Dateisystemfragmentation erheblich reduziert. Die Leistung wird erhöht, da die Dateiinhalte nicht über das gesamte Dateisystem verteilt werden.