Linux Deutsch

ReiserFS: Eigenschaften, Einsatzbereiche und Grenzen des Linux-Dateisystems

ReiserFS erklärt: Journaling, B-Bäume, Tail Packing, historische Einsatzbereiche, Grenzen, Wartung, Sicherheitsbewertung und Migration zu ext4 oder XFS.

ReiserFS ist ein journalingfähiges Dateisystem für Linux, das historisch besonders für Verzeichnisse mit sehr vielen kleinen Dateien bekannt war. Heute ist es vor allem bei der Wartung älterer Systeme relevant. Für neue produktive Installationen sind ext4 oder XFS in der Regel die bessere Wahl, weil sie aktueller gepflegt und umfassender unterstützt werden.

Dieser Überblick erklärt die technische Arbeitsweise, frühere Stärken, bekannte Grenzen sowie einen vorsichtigen Umgang mit bestehenden ReiserFS-Volumes.

ReiserFS einordnen

Ein Dateisystem organisiert Dateien, Verzeichnisse und zugehörige Metadaten auf einem Speichergerät. Es ist nicht dasselbe wie eine Partition, ein Logical Volume oder ein RAID-Verbund:

  • Eine Partition teilt einen Datenträger logisch in Bereiche auf.
  • Ein Logical Volume ist ein logisches Speichergerät, das beispielsweise mit LVM aus physischem Speicher bereitgestellt wird.
  • RAID verbindet mehrere Datenträger für Redundanz, Leistung oder Kapazität. RAID ersetzt kein Backup.
  • Das Dateisystem wird auf einer Partition, einem Logical Volume oder einem geeigneten RAID-Gerät angelegt.

ReiserFS wurde unter maßgeblicher Leitung von Hans Reiser und der Organisation Namesys entwickelt. Die Software wurde unter der GPL veröffentlicht. Die GPL ist eine freie Softwarelizenz, die unter anderem die Nutzung, Untersuchung und Weitergabe unter den Lizenzbedingungen erlaubt.

ReiserFS auf einen Blick

MerkmalAngabeEinordnung
TypJournaling-DateisystemFür Linux entwickelt
LizenzGPLFreie Softwarelizenz
Historische maximale Dateigröße8 TBDokumentierter historischer Grenzwert
Historische maximale Dateisystemgröße16 TBDokumentierter historischer Grenzwert
Historische maximale Dateinamenlänge4032 ByteAbhängig von Umgebung und Werkzeugen
StärkeViele kleine Dateien und platzsparende AblageHistorischer Vorteil bei bestimmten Workloads
Heutiger StatusFür Neuanlagen nicht empfohlenLegacy-Technik mit eingeschränkter Zukunftsperspektive

Funktionsprinzip und zentrale Eigenschaften

Journaling

Journaling bedeutet, dass geplante oder ausgeführte Änderungen des Dateisystems in einem Journal protokolliert werden. Das Journal ist ein spezieller Bereich für Dateisystemtransaktionen. Nach einem Stromausfall oder Absturz kann das System anhand dieses Protokolls schneller feststellen, welche Änderungen vollständig abgeschlossen und welche noch offen waren.

Journaling verhindert nicht automatisch Datenverlust. Es verbessert vor allem die strukturelle Konsistenz des Dateisystems und kann die Wiederherstellung nach einer Unterbrechung beschleunigen. Nicht gespeicherte Anwendungsdaten oder bereits beschädigte Hardware werden dadurch nicht gerettet.

B-Bäume und Metadaten

ReiserFS organisiert Verzeichnisse und Metadaten mit einer B-Baum-basierten Struktur. Ein B-Baum ist eine ausgeglichene Baumstruktur zur effizienten Verwaltung sortierter Einträge. Dadurch können Such-, Einfüge- und Löschvorgänge auch in großen Verzeichnissen mit vielen Einträgen effizient durchgeführt werden.

Metadaten sind beschreibende Informationen wie Dateiname, Eigentümer, Zugriffsrechte, Dateigröße und Zeitstempel. Die Organisation dieser Informationen beeinflusst besonders Operationen wie das Anlegen, Umbenennen und Löschen vieler Dateien.

Tail Packing

Tail Packing bezeichnet eine Technik, bei der kleine Dateienden oder sehr kleine Dateien gemeinsam in einem Speicherbereich abgelegt werden können. Ohne eine solche Technik kann der ungenutzte Rest eines teilweise belegten Blocks viel Platz verschwenden. Tail Packing senkt diese Verschwendung und kann die Speicherauslastung bei kleinen Dateien verbessern.

Die Kombination aus B-Bäumen und Tail Packing war besonders bei tiefen Verzeichnisbäumen, vielen Metadatenoperationen und großen Mengen kleiner Dateien interessant. Die tatsächliche Leistung hängt jedoch auch von Hardware, Kernel, Anwendung, Cache-Verhalten und Dateizugriffsmuster ab.

Stärken und historische Einsatzszenarien

ReiserFS war historisch attraktiv, wenn ein System sehr viele kleine Dateien verwalten musste. Beispiele sind:

  • Mail-Spools mit vielen einzelnen Nachrichten;
  • News-Server mit zahlreichen Artikeln und Verzeichnissen;
  • Quellcodebäume mit vielen kleinen Text- und Konfigurationsdateien;
  • Dokumentenablagen mit vielen einzelnen Dateien.

Tail Packing konnte in solchen Szenarien Speicherplatz sparen. Die B-Baum-Strukturen konnten außerdem Operationen in umfangreichen Verzeichnissen unterstützen. ReiserFS konnte auf logischen Volumes und auf RAID-basierten Speicherarchitekturen eingesetzt werden. Das war jedoch kein exklusiver Vorteil: Auch andere Dateisysteme können auf geeigneten Blockgeräten, LVM-Strukturen oder RAID-Volumes verwendet werden.

Größen- und Namensgrenzen

Historisch dokumentierte ReiserFS-Grenzen umfassen eine maximale Dateigröße von 8 TB, eine maximale Dateisystemgröße von 16 TB und eine maximale Dateinamenlänge von 4032 Byte.

Diese Werte sind nicht als universelle Zusicherung für jede Installation zu verstehen. Konkrete Grenzen können von Kernel-Version, Prozessorarchitektur, Treibern, Blockgerät, Distribution sowie den eingesetzten Werkzeugversionen abhängen. Vor einer Planung müssen daher die lokale Dokumentation und die tatsächlich unterstützte Umgebung geprüft werden.

Unterstützung durch Linux-Distributionen

ReiserFS wurde in der Vergangenheit unter anderem als Standarddateisystem oder bevorzugte Auswahl in Elive, Xandros, Linspire und GoboLinux verwendet. Eine frühere Standardauswahl beschreibt den damaligen Distributionszustand, ist aber keine heutige Empfehlung.

Moderne Distributionen und Installer bieten ReiserFS häufig gar nicht mehr oder nur eingeschränkt an. Auch die Verfügbarkeit von Kernel-Modulen, reiserfsprogs und Rettungsumgebungen kann je nach Release deutlich variieren.

Wartungszustand und Sicherheitsbewertung

Die Weiterentwicklung von ReiserFS ist langfristig stagnierend. Dadurch ist die Zukunftsperspektive gegenüber aktiv gepflegten Dateisystemen eingeschränkt. Für neue produktive Installationen sollte ReiserFS daher nicht ausgewählt werden.

Bei einer Bestandsinstallation ist die Situation anders: Ein vorhandenes, funktionierendes Dateisystem muss nicht ohne Planung sofort ersetzt werden. Es sollte zunächst inventarisiert, gesichert und hinsichtlich seiner betrieblichen Bedeutung bewertet werden. Danach kann ein kontrollierter Weiterbetrieb oder eine Migration geplant werden.

  • Regelmäßige Backups erstellen und deren Rücksicherung testen.
  • Bei kritischen Daten zusätzlich ein Image oder eine zweite Kopie einplanen.
  • Kernel-, Distributions- und Werkzeugunterstützung der eingesetzten Umgebung dokumentieren.
  • Eine Migration mit ausreichend freiem Speicher und einem Rollback-Plan vorbereiten.

Die technische Bewertung sollte nicht nur auf die Person des ursprünglichen Entwicklers fokussieren. Entscheidend sind vor allem Projektpflege, Kernel-Unterstützung, Verfügbarkeit von Verwaltungs- und Rettungswerkzeugen sowie die Unterstützung durch die verwendete Distribution.

Ein bestehendes ReiserFS-Dateisystem verwalten

Dateisystemtyp und Volume identifizieren

Beginne mit einer Bestandsaufnahme. Die folgenden Befehle zeigen Dateisystemtypen, Geräte und UUIDs an und verändern keine Daten:

lsblk -f
sudo blkid

Prüfe bei LVM- oder RAID-Systemen außerdem, ob die darunterliegenden Speichergeräte aktiviert und korrekt zusammengesetzt sind. Ein falscher Gerätepfad kann zu Datenverlust führen.

Schreibgeschützt mounten

Für Prüfung, Rettung und Migration ist ein schreibgeschützter Mount vorzuziehen:

sudo mount -t reiserfs -o ro /dev/DEVICE /mnt/reiserfs

/dev/DEVICE und /mnt/reiserfs sind Platzhalter. Vor dem Befehl muss das korrekte Gerät eindeutig bestimmt und der Mountpunkt vorbereitet werden.

Werkzeuge prüfen

Die Werkzeugsammlung reiserfsprogs enthält Programme zum Erstellen, Prüfen und Verwalten von ReiserFS. Paketverfügbarkeit und Versionen hängen von Distribution und Release ab:

which mkreiserfs fsck.reiserfs
mkreiserfs --version
fsck.reiserfs --version

Prüfen ist nicht dasselbe wie reparieren

fsck.reiserfs kann ein ReiserFS-Dateisystem prüfen und je nach Option auch verändern. Eine nicht verändernde Prüfung eines ungemounteten Dateisystems kann beispielsweise so aussehen:

sudo fsck.reiserfs --check /dev/DEVICE

Bestandsverwaltung mit fstab

Ein vorhandenes Volume kann über seine UUID in /etc/fstab eingetragen sein:

UUID=BEISPIEL-UUID /daten reiserfs defaults 0 2

Ersetze die Beispiel-UUID durch die tatsächliche UUID und prüfe Mountpunkt, Optionen und Berechtigungen. Dieser Eintrag dient der Verwaltung eines Altbestands und ist keine Empfehlung für neue ReiserFS-Installationen. Mehr Grundlagen bietet der Beitrag zur Datei /etc/fstab.

Typische Fehlerbilder

Das Dateisystem lässt sich nicht mounten

  • Mit lsblk -f und blkid das richtige Gerät bestimmen.
  • Bei LVM oder RAID zuerst die Speicherarchitektur korrekt aktivieren.
  • Fehlende Kernel-Unterstützung oder nicht installierte reiserfsprogs prüfen.
  • Ein schreibgeschütztes Mounten versuchen.
  • Vor Prüf- oder Reparaturversuchen ein Image oder Backup anlegen.

Mögliche Ursachen sind außerdem beschädigte Metadaten, ein inkonsistentes Journal oder ein falscher Datenträgerpfad.

Nach einem Absturz wird eine Prüfung verlangt

Ein Stromausfall oder erzwungener Neustart kann unvollständig abgeschlossene Transaktionen hinterlassen. Hänge das Dateisystem aus, prüfe zuerst den Datenträgerzustand und die Sicherungen und führe anschließend eine nicht verändernde Prüfung durch. Reparaturoptionen dürfen erst nach einer verifizierten Sicherung, auf einem ungemounteten Dateisystem und mit versionspassender Dokumentation eingesetzt werden.

Werkzeuge fehlen

Wenn eine Distribution reiserfsprogs nicht mehr ausliefert, müssen Paketquellen und Release-Dokumentation geprüft werden. Für Datenrettung kann eine passende Umgebung mit benötigtem Treiber und Werkzeug erforderlich sein. Mittelfristig sollte eine Migration geplant werden, statt dauerhaft von Legacy-Werkzeugen abhängig zu bleiben.

Migration auf ein modernes Dateisystem

Eine direkte In-Place-Konvertierung von ReiserFS zu ext4 oder XFS ist kein verlässlicher Standardweg. Plane deshalb eine Migration über ein neues Ziel-Dateisystem.

  1. Bestand aufnehmen: Geräte, Mountpunkte, Datenmenge, Anwendungen, Eigentümer und Abhängigkeiten dokumentieren.
  2. Backup oder Image erstellen: Sicherung anlegen und die Wiederherstellung zumindest stichprobenartig testen.
  3. Zieldateisystem auswählen: ext4 eignet sich häufig als allgemeines Linux-Dateisystem; XFS ist besonders bei großen Datenmengen und hoher Skalierung interessant.
  4. Zielvolume bereitstellen: Ausreichend freien Speicher einplanen und das Zielgerät eindeutig identifizieren.
  5. Zieldateisystem anlegen: Die folgenden Befehle löschen den Inhalt des angegebenen Zielgeräts:
sudo mkfs.ext4 /dev/NEW_DEVICE
sudo mkfs.xfs /dev/NEW_DEVICE
  1. Daten übertragen: Quelle und Ziel korrekt mounten und relevante Metadaten erhalten.
sudo rsync -aHAX --numeric-ids --info=progress2 /mnt/reiserfs/ /mnt/neu/

Die Optionen erhalten unter anderem rekursive Strukturen, Hardlinks, ACLs und erweiterte Attribute. ACLs und Extended Attributes müssen auf Quelle, Ziel und den Mountoptionen unterstützt werden. Ein zweiter Synchronisationslauf kurz vor der Umschaltung reduziert das Zeitfenster für Änderungen.

  1. Metadaten prüfen: Eigentümer, Rechte, Zeitstempel, ACLs, erweiterte Attribute, Hardlinks und Sonderdateien kontrollieren.
  2. Mount-Konfiguration ändern: UUID, Mountpunkt und Optionen in fstab anpassen.
  3. Abnahme durchführen: Anwendungen testen, Datenbestand vergleichen und Protokolle prüfen.
  4. Rollback offenhalten: Das alte Volume erst löschen oder außer Betrieb nehmen, wenn die neue Umgebung nachweislich funktioniert.

Migrationscheckliste

SchrittZielKontrolle oder Risiko
BestandsaufnahmeAbhängigkeiten und Datenumfang kennenGerät, UUID und Mountpunkt nicht verwechseln
Backup beziehungsweise ImageRückkehr zum Ausgangszustand ermöglichenWiederherstellung testen
Zieldateisystem auswählenPassende moderne Plattform bestimmenWorkload und Distributionssupport bewerten
Zielvolume erstellenNeuen Speicher vorbereitenFalsches Gerät würde gelöscht
DatenübertragungDateien und Metadaten kopierenFreien Speicher und Kopierfehler prüfen
MetadatenprüfungSemantik der Dateien erhaltenACLs, xattrs, Hardlinks und Sonderdateien kontrollieren
fstab und Mountpunkte umstellenSystem auf das Ziel zeigen lassenBoot- und Mount-Test durchführen
Abnahme und RückfallplanBetrieb sicher abschließenAlte Kopie bis zur Freigabe behalten

Vergleich mit ext4 und XFS

KriteriumReiserFSext4XFS
Projekt- und DistributionsunterstützungStagnierend und häufig reduziertSehr breit und etabliertBreit und aktiv unterstützt
Eignung für NeuanlagenNicht empfohlenHäufige StandardwahlGeeignet bei passendem Workload
Viele kleine DateienHistorisch eine Stärke, einschließlich Tail PackingGute allgemeine EignungAbhängig von Workload und Layout
Große Dateien und DateisystemeHistorische Grenzen und eingeschränkte PerspektiveGute allgemeine SkalierungBesonders auf große Datenmengen und Skalierung ausgerichtet
Verwaltungs- und RettungswerkzeugeVerfügbarkeit kann problematisch seinSehr umfangreichUmfangreich und gut integriert
Typische EinsatzempfehlungBestand betreiben oder geplant migrierenAllgemeine Linux-SystemeGroße Datenmengen, Server- und Skalierungs-Workloads

Die Wahl sollte nach Workload, Distribution, Supportanforderungen, Backup-Strategie und Betriebserfahrung erfolgen. Für kleine Dateien ist ein Benchmark mit dem realen Zugriffsmuster aussagekräftiger als ein historischer Vergleichswert.

Entscheidungshilfe

  • Neue allgemeine Linux-Installation: meist ext4 wählen, wenn eine breit unterstützte Standardlösung gefragt ist.
  • Große Datenmengen oder hohe Skalierungsanforderungen: XFS prüfen, sofern Anwendungen und Wiederherstellungsprozesse dazu passen.
  • Bestehendes ReiserFS: Backup- und Wiederherstellbarkeit zuerst sicherstellen, danach Weiterbetrieb oder Migration entscheiden.
  • Kritische Altanwendung: Kernel-, Paket- und Rettungsumgebung dokumentieren und einen zeitnahen Migrationsplan erstellen.

Für weiterführende Grundlagen eignen sich die Beiträge zu ext4, zu XFS und zur Dateisystemprüfung.