ReiserFS - ReiserFS

Nicht zu verwechseln mit ReFS .
Dieser Artikel behandelt ReiserFS Version 3. Für Version 4 siehe Reiser4 .
ReiserFS 3.6
Entwickler Namesys
Vollständiger Name ReiserFS
Eingeführt 2001 ; Vor 20 Jahren mit Linux 2.4.1 ( 2001 )
Partitionskennung
Strukturen
Verzeichnisinhalt B+ Baum
Dateizuordnung Bitmap
Grenzen
max. Volumengröße 16 TiB
max. Dateigröße 1 EiB (8 TiB auf 32-Bit-Systemen)
max. Anzahl der Dateien 2 32 -3 (~4 Milliarden)
max. Dateinamenlänge 4032 Byte, begrenzt auf 255 durch Linux VFS
Erlaubte Zeichen in Dateinamen Alle Bytes außer NUL und '/'
Merkmale
Daten aufgezeichnet Modifikation (mtime), Metadatenänderung (ctime), Zugriff (atime)
Datumsbereich 14. Dezember 1901 – 18. Januar 2038
Datumsauflösung 1 s
Gabeln Erweiterte Attribute
Dateisystemberechtigungen Unix-Berechtigungen, ACLs und beliebige Sicherheitsattribute
Transparente Kompression Nein
Transparente Verschlüsselung Nein
Sonstiges
Unterstützte Betriebssysteme Linux, ReactOS

ReiserFS ist ein Allzweck- Journaling-Dateisystem, das ursprünglich von einem Team bei Namesys unter der Leitung von Hans Reiser entworfen und implementiert wurde . ReiserFS wird derzeit unter Linux (ohne Quotenunterstützung) unterstützt, das als GPLv2 lizenziert ist . Eingeführt in Version 2.4.1 des Linux-Kernels war es das erste Journaling-Dateisystem, das in den Standard-Kernel aufgenommen wurde. ReiserFS war das Standarddateisystem in Novells SUSE Linux Enterprise, bis Novell beschloss, am 12. Oktober 2006 für zukünftige Versionen auf ext3 umzusteigen.

Namesys betrachtete ReiserFS Version 3.6, die ein neues On-Disk-Format einführte, das größere Dateigrößen ermöglichte, jetzt gelegentlich als Reiser3 bezeichnet, als stabil und funktionsvoll und stellte die Entwicklung mit Ausnahme von Sicherheitsupdates und kritischen Bugfixes ein, um sich darauf zu konzentrieren sein Nachfolger Reiser4 . Namesys ging 2008 nach der Verurteilung von Reiser wegen Mordes aus dem Geschäft. Das Produkt wird nun von Freiwilligen als Open Source gepflegt. Die reiserfsprogs 3.6.27 wurden am 25. Juli 2017 veröffentlicht.

Merkmale

Zum Zeitpunkt seiner Einführung bot ReiserFS Funktionen, die in bestehenden Linux-Dateisystemen nicht verfügbar waren. Ein Beispiel ist Tail Packing – ein Schema zur Reduzierung der internen Fragmentierung . Tail Packing kann einen erheblichen Einfluss auf die Leistung haben. Reiser4 hat dies möglicherweise durch Packen von Schwänzen verbessert, wo es die Leistung nicht beeinträchtigt.

Design

ReiserFS speichert Datei - Metadaten ( „stat Elemente“), Verzeichniseinträge ( „Verzeichniselemente“), inode Blocklisten ( „indirekte Elemente“) und Schwanz von Dateien ( „direct Artikel“) in einem einzigen kombinierten B + Baum durch ein verkeilten universelle Objekt-ID. Den Knoten des Baums zugeordnete Plattenblöcke sind "formatierte interne Blöcke". Blöcke für Blattknoten (in denen Elemente Ende-zu-Ende verpackt sind) sind "formatierte Blattblöcke". Alle anderen Blöcke sind "unformatierte Blöcke", die Dateiinhalte enthalten. Verzeichniselemente mit zu vielen Einträgen oder indirekte Elemente, die zu lang sind, um in einen Knoten zu passen, gehen in den rechten Blattnachbarn über. Die Blockzuweisung wird durch Bitmaps des freien Speicherplatzes an festen Orten verfolgt.

Im Gegensatz dazu verwendeten ext2 und andere Berkeley FFS- ähnliche Dateisysteme dieser Zeit einfach eine feste Formel zur Berechnung der Inode-Positionen, wodurch die Anzahl der Dateien, die sie enthalten können, begrenzt wurde. Die meisten dieser Dateisysteme speichern auch Verzeichnisse als einfache Listen von Einträgen, was Verzeichnissuchen und lineare Zeitoperationen durchführt und die Leistung bei sehr großen Verzeichnissen verschlechtert. Das Single- B+-Tree- Design in ReiserFS vermeidet diese beiden Probleme aufgrund besserer Skalierbarkeitseigenschaften.

Leistung

Im Vergleich zu ext2 und ext3 in Version 2.4 des Linux-Kernels kann ReiserFS beim Umgang mit Dateien unter 4  KiB und aktiviertem Tail Packing schneller sein.

Vor Linux 2.6.33 hat ReiserFS stark den Big Kernel Lock (BKL) – eine globale Kernel-weite Sperre – verwendet, die für Systeme mit mehreren Kernen nicht gut skaliert, da die kritischen Codeteile immer nur von einem Kern gleichzeitig ausgeführt werden .

Verwendungszweck

ReiserFS war das Standarddateisystem in SuSE Linux seit Version 6.4 (veröffentlicht im Jahr 2000), bis der Wechsel zu ext3 in SUSE Linux Enterprise 10.2 und openSUSE 11 im Jahr 2006 angekündigt wurde.

Jeff Mahoney von SUSE schrieb am 14. September 2006 einen Beitrag, in dem er vorschlug, für das Standardinstallationsdateisystem von ReiserFS auf ext3 umzusteigen . Als Gründe nannte er Skalierbarkeit, "Leistungsprobleme mit erweiterten Attributen und ACLs ", "eine kleine und schrumpfende Entwickler-Community" und " Reiser4 ist kein inkrementelles Update und erfordert eine Neuformatierung, die für die meisten Menschen unzumutbar ist." Am 4. Oktober schrieb er einen Antwortkommentar in einem Blog, um einige Fragen zu klären. Er schrieb, dass sein Vorschlag für den Wechsel nichts damit zu tun habe, dass Hans Reiser wegen Mordes vor Gericht stehe. Mahoney schrieb, er sei "besorgt, dass die Leute eine Verbindung herstellen würden, wo keine existierte" und dass "das Timing völlig zufällig ist und die Motivation nicht damit zusammenhängt".

Kritik

Einige Verzeichnisoperationen (einschließlich unlink (2)) sind auf ReiserFS nicht synchron , was bei Anwendungen, die stark auf dateibasierte Sperren angewiesen sind (wie Mail Transfer Agents qmail und Postfix ), zu Datenbeschädigungen führen kann, wenn die Maschine anhält, bevor sie die Scheibe.

Es gibt keine Programme, um ein ReiserFS-Dateisystem speziell zu defragmentieren , obwohl Tools geschrieben wurden, um den Inhalt fragmentierter Dateien automatisch zu kopieren, in der Hoffnung, dass mehr zusammenhängende Blöcke freien Speicherplatzes gefunden werden können. Für das nächste Reiser4-Dateisystem war jedoch ein "Repacker"-Tool geplant, um mit der Dateifragmentierung umzugehen. Mit dem Aufkommen von Solid State Disks wurde dieses Problem irrelevant.

fsck

Der Baumwiederherstellungsprozess von fsck von ReiserFS hat von der *nix-Community viel Kritik auf sich gezogen: Wenn das Dateisystem so stark beschädigt wird, dass sein interner Baum unbrauchbar wird, kann die Durchführung eines Baumwiederherstellungsvorgangs vorhandene Dateien weiter beschädigen oder neue Einträge mit unerwartetem Inhalt hinzufügen. Diese Aktion ist jedoch nicht Teil des normalen Betriebs oder einer normalen Dateisystemprüfung und muss vom Administrator explizit initiiert und bestätigt werden.

ReiserFS v3-Images sollten nicht auf einer ReiserFS v3- Partition gespeichert werden (zB Backups oder Disk-Images für Emulatoren) ohne diese zu transformieren (zB durch Komprimieren oder Verschlüsseln), um den Neuaufbau nicht zu verwirren. Die Neuformatierung einer vorhandenen ReiserFS v3-Partition kann auch Daten hinterlassen, die den Neuaufbau verwirren und Dateien vom alten System wieder auftauchen lassen. Dadurch können böswillige Benutzer auch absichtlich Dateien speichern, die den Rebuilder verwirren. Da die Metadaten nach einer Dateisystemprüfung immer in einem konsistenten Zustand sind, bedeutet Korruption hier, dass Inhalte von Dateien auf unerwartete Weise mit den Metadaten des enthaltenen Dateisystems zusammengeführt werden. Der ReiserFS-Nachfolger Reiser4 behebt dieses Problem.

Frühere Probleme

ReiserFS in Versionen des Linux-Kernels vor 2.4.16 wurden von Namesys als instabil angesehen und nicht für den produktiven Einsatz empfohlen, insbesondere in Verbindung mit NFS .

Frühe Implementierungen von ReiserFS (vor denen in Linux 2.6.2) waren auch anfällig für Schreibfehler außerhalb der Reihenfolge. Aber die aktuelle Journaling-Implementierung in ReiserFS ist jetzt auf dem Niveau der "geordneten" Journaling-Ebene von ext3 .

Siehe auch

Verweise

Externe Links