VMware ESXi and vSphere Cluster Management

ReiserFS: Eigenschaften, Einsatz und Migration eines historischen Linux-Dateisystems

ReiserFS verständlich erklärt: Journaling, B-Bäume, Tail Packing, Grenzen, Prüfung mit reiserfsck und sichere Migration auf ext4, XFS oder Btrfs.

ReiserFS ist ein historisches Journaling-Dateisystem für Linux. Es wurde von Hans Reiser und Namesys entwickelt und unter der GPL veröffentlicht. Früher war es besonders für Systeme mit sehr vielen kleinen Dateien interessant. Für neue Installationen ist es heute jedoch nicht mehr geeignet: Die Weiterentwicklung ist seit vielen Jahren praktisch eingestellt, die Werkzeugunterstützung nimmt ab und ReiserFS wurde aus neueren Linux-Kernelversionen entfernt.

Wer noch eine ReiserFS-Partition besitzt, sollte sie nicht vorschnell formatieren. Zuerst müssen Dateisystem, Datenbestand, Hardwarezustand und Sicherungen erfasst werden. Anschließend ist eine geplante Migration auf ein unterstütztes Dateisystem wie ext4, XFS oder Btrfs sinnvoll.

Einordnung und heutiger Status

Ein Dateisystem vermittelt zwischen Anwendungen und dem Blockspeicher eines Datenträgers. Anwendungen arbeiten mit Dateien und Verzeichnissen. Das Dateisystem übersetzt diese Struktur in Blöcke, verwaltet Dateinamen, Besitzer, Rechte und Zeitstempel und kommuniziert mit darunterliegenden Schichten wie Partitionen, LVM, RAID und dem physischen Laufwerk.

ReiserFS war eines der frühen Linux-Dateisysteme mit Journaling. Beim Journaling werden bestimmte Änderungen zunächst in einem Protokoll, dem Journal, festgehalten. Nach einem Absturz kann das Dateisystem dadurch schneller wieder in einen konsistenten strukturellen Zustand gebracht werden. Journaling bedeutet aber nicht, dass automatisch alle Nutzdaten vor Verlust geschützt sind.

Die frühere Verbreitung von ReiserFS beruhte unter anderem auf seiner guten Behandlung vieler kleiner Dateien. Heute überwiegen jedoch die Nachteile des veralteten Ökosystems:

• Die aktive Weiterentwicklung ist seit vielen Jahren praktisch eingestellt.
• Neuere Linux-Kernel enthalten den ReiserFS-Treiber nicht mehr oder unterstützen ihn nicht mehr regulär.
• Aktuelle Distributionen liefern die passenden Verwaltungs- und Reparaturwerkzeuge oft nicht standardmäßig.
• Ein modernes Rettungssystem kann ein altes ReiserFS möglicherweise weder mounten noch reparieren.
• Fehlt der Kernel-Treiber, können selbst vorhandene Daten ohne ein geeignetes älteres Rettungssystem schwer zugänglich sein.

Grundprinzipien und Architektur

Blockorientierte Speicherung

ReiserFS ist klassisch blockorientiert. Ein Block ist eine Einheit, in der das Dateisystem Daten oder Verwaltungsinformationen speichert. Eine Datei besteht aus Nutzdaten; zusätzlich benötigt das Dateisystem Metadaten. Metadaten beschreiben beispielsweise Dateiname, Besitzer, Zugriffsrechte, Zeitstempel, Größe und die Zuordnung zu einem Verzeichnis.

Verzeichnisse sind dabei keine bloßen Textlisten. Das Dateisystem muss Einträge effizient finden, einfügen und löschen können. ReiserFS organisiert viele Metadaten und Verzeichniseinträge mit einer B-Baum-basierten Struktur. Ein B-Baum ist ein ausgewogener Suchbaum, dessen Knoten mehrere Einträge enthalten können. Dadurch bleiben Such- und Änderungsoperationen auch bei großen Beständen praktikabel.

Journaling und Nutzdaten

Das Journal schützt vor allem die Konsistenz der Dateisystemstrukturen. Nach einem Stromausfall kann es beispielsweise helfen, angefangene Metadatenänderungen zu erkennen und abzuschließen oder zurückzunehmen. Das ist etwas anderes als eine Sicherung der Datei: Ein bereits gelöschtes Dokument, ein durch eine fehlerhafte Anwendung überschriebenes Bild oder Daten auf einem zerstörten Laufwerk werden durch Journaling nicht wiederhergestellt.

Tail Packing

Tail Packing bezeichnet die platzsparende Speicherung kleiner Dateireste. Bei einer blockorientierten Ablage belegt eine kleine Datei oder das Ende einer größeren Datei sonst möglicherweise einen ganzen Block, obwohl nur ein Teil davon genutzt wird. ReiserFS kann solche Reste mehrerer Dateien gemeinsam unterbringen.

• Speicherverbrauch: Weniger ungenutzter Platz in teilweise gefüllten Blöcken.
• Leistung: Je nach Zugriffsmuster kann die geringere Platzbelegung hilfreich sein; zusätzliche Verwaltungsarbeit kann einzelne Zugriffe aber auch beeinflussen.
• Datenrettung: Werkzeuge, die von einer einfachen Zuordnung ganzer Datenblöcke ausgehen, müssen gepackte Dateireste korrekt interpretieren. Das kann forensische Auswertung und Wiederherstellung erschweren.

Stärken und frühere Einsatzszenarien

Die Architektur war besonders dort interessant, wo sehr viele kleine Dateien verwaltet wurden. Beispiele aus der historischen Praxis sind Mailspools mit vielen einzelnen Nachrichten, Quelltextbäume, Paketdatenbanken sowie kleinere Dateien von Webanwendungen.

Bei solchen Workloads können effiziente Verzeichnisstrukturen und Tail Packing den Metadaten- und Speicherbedarf reduzieren. Das ist eine historische Stärke, bedeutet aber nicht, dass ReiserFS unter jeder Belastung automatisch schneller ist als moderne Dateisysteme. Hardware, Kernel, Mount-Optionen, Dateimuster und die konkrete Anwendung beeinflussen die Ergebnisse.

ReiserFS auf LVM und RAID

ReiserFS konnte auf einem Logical Volume oder auf einem RAID-Gerät verwendet werden. Dabei handelt es sich um getrennte Schichten:

• LVM steht für Logical Volume Manager. LVM stellt flexible logische Blockbereiche bereit, die aus physischen Speicherbereichen zusammengesetzt werden können.
• RAID kombiniert mehrere Laufwerke für Redundanz, Leistung oder zusätzliche Kapazität.
• ReiserFS liegt als Dateisystem auf dem bereitgestellten Blockgerät, etwa einem Logical Volume oder einem RAID-Verbund.

LVM und RAID sind keine ReiserFS-spezifischen Funktionen. Für eine Migration kann beispielsweise ein neues Logical Volume mit ext4 oder XFS erstellt werden, während das alte Volume zunächst unverändert als Quelle dient. RAID und insbesondere RAID-Redundanz ersetzen kein Backup, weil versehentliches Löschen, Schadsoftware und viele logische Fehler gespiegelt werden können.

Grenzen, Risiken und technische Kennzahlen

Für ReiserFS werden in älteren technischen Dokumentationen häufig folgende Größen genannt: bis zu 8 TiB pro Datei, bis zu 16 TiB pro Dateisystem und bis zu 4032 Byte Dateinamenlänge. Diese Werte sind als historische Angaben zu verstehen. Tatsächlich nutzbare Grenzen hängen unter anderem von Kernelversion, Prozessorarchitektur, Blockgröße, Bibliotheken und den eingesetzten Werkzeugen ab.

Wichtiger als die historischen Maximalwerte sind heute die Betriebsrisiken. Ein Dateisystem mit geringerer Tool-Unterstützung kann bei einem Hardwaredefekt, einer beschädigten Struktur oder einem Systemwechsel zum Engpass werden. Auch eine neue Distribution kann die benötigten Komponenten nicht mehr enthalten.

Journaling schützt nicht vor:

• versehentlichem Löschen oder Überschreiben,
• Fehlern in Anwendungen oder Skripten,
• defekten Laufwerken und nicht lesbaren Sektoren,
• Feuer, Diebstahl oder anderen Schäden am System,
• Ransomware und absichtlicher Verschlüsselung.

Deshalb gehören ein getestetes Backup, eine Wiederherstellungsprobe und ein dokumentierter Migrations- und Rückfallplan zusammen. Ein Backup gilt erst dann als verlässlich, wenn sich daraus tatsächlich Dateien oder ein vollständiges System wiederherstellen lassen.

ReiserFS in der Praxis erkennen und verwalten

Bei der Bestandsaufnahme müssen drei Dinge unterschieden werden:

• Die Partitionskennung beschreibt, wie eine Partitionstabelle ein Gerät klassifiziert.
• Die erkannte Dateisystemsignatur stammt aus den Strukturen auf dem Blockgerät.
• Das tatsächlich eingehängte Dateisystem und sein Mountpoint zeigen, wie der laufende Kernel das Gerät verwendet.

Ein vorhandenes ReiserFS kann beispielsweise so untersucht werden:

lsblk -f
sudo blkid
findmnt -t reiserfs
mount

lsblk -f zeigt Blockgeräte, erkannte Dateisystemtypen, Labels und UUIDs. blkid liest erkannte Signaturen und Kennungen. findmnt zeigt tatsächlich eingehängte Dateisysteme; der Filter findet ReiserFS-Mounts. Gerätenamen müssen immer mit Größe, UUID und Mountpoint abgeglichen werden. Ein falsches Zielgerät kann bei späteren Befehlen zu dauerhaftem Datenverlust führen.

Nur lesend mounten

Für Diagnose und Kopieren sollte eine vorhandene Quelle möglichst nur lesbar eingehängt werden:

sudo mkdir -p /mnt/reiserfs-source
sudo mount -t reiserfs -o ro /dev/DEVICE /mnt/reiserfs-source

DEVICE muss durch die zuvor zweifelsfrei identifizierte Partition oder das Logical Volume ersetzt werden. Dieser Befehl funktioniert nur, wenn der laufende Kernel einen ReiserFS-Treiber besitzt. Außerdem können passende Benutzerwerkzeuge aus reiserfsprogs erforderlich sein. Falls der aktuelle Kernel ReiserFS nicht unterstützt, sollte ein vertrauenswürdiges älteres Rettungssystem mit Leseunterstützung verwendet werden.

Konsistenzprüfung und Datenrettung

reiserfsck ist das zentrale Werkzeug aus reiserfsprogs zur Prüfung und Reparatur eines ReiserFS-Dateisystems. Zwischen den Betriebsarten muss klar unterschieden werden:

• Eine reine Prüfung, etwa mit --check, analysiert die Strukturen ohne beabsichtigte Korrektur.
• Korrigierende Optionen verändern Metadaten und können Fehler beheben, bergen aber bei falscher Anwendung Risiken.
• Wiederherstellungs- oder Rekonstruktionsmodi sind besonders risikoreich und sollten nur mit einem nachvollziehbaren Plan und einer Kopie des Originalzustands eingesetzt werden.

Das Dateisystem muss vor der Prüfung ausgehängt sein. fsck oder reiserfsck darf nicht auf einem eingehängten und beschreibbaren Dateisystem laufen, weil gleichzeitige Änderungen die Analyse verfälschen und zusätzliche Schäden verursachen können.

sudo reiserfsck --check /dev/DEVICE

Vor jeder schreibenden Reparatur sollte ein sektor- oder blockbasiertes Abbild des Geräts erstellt werden. Zusätzlich müssen wichtige Daten auf einem unabhängigen Ziel gesichert werden. Bei I/O-Fehlern sind SMART-Werte, Systemprotokolle und die Verkabelung beziehungsweise Stromversorgung zu prüfen. Ein unvollständiges Journal, beschädigte Metadaten, defekte Medien oder fehlender Kernel-Support können die Wiederherstellung begrenzen. Kein Reparaturwerkzeug kann nicht mehr lesbare physische Daten zuverlässig zurückholen.

Migration auf ein unterstütztes Dateisystem

Eine direkte In-Place-Umwandlung von ReiserFS zu ext4, XFS oder Btrfs ist im Regelfall nicht vorgesehen. Der sichere Weg ist eine dateibasierte Migration: neues Dateisystem anlegen, Daten kopieren und die Konfiguration erst nach erfolgreicher Prüfung umstellen.

Beispiel: neue ext4-Zielpartition

Das folgende Beispiel setzt voraus, dass das Zielgerät eindeutig identifiziert wurde. Das Formatieren löscht den Inhalt des Zielgeräts.

sudo mkfs.ext4 -L daten-neu /dev/TARGET_DEVICE
sudo mkdir -p /mnt/target
sudo mount /dev/TARGET_DEVICE /mnt/target
sudo rsync -aHAXx --numeric-ids --info=progress2 /mnt/reiserfs-source/ /mnt/target/

Die Optionen von rsync haben dabei unterschiedliche Aufgaben:

• -a erhält die rekursive Struktur sowie zentrale Attribute wie Rechte und Zeitstempel.
• -H erhält Hardlinks.
• -A übernimmt POSIX-ACLs.
• -X übernimmt Extended Attributes.
• --numeric-ids verwendet numerische Benutzer- und Gruppenkennungen statt Namen.
• -x verhindert, dass unterhalb der Quelle weitere eingehängte Dateisysteme mitkopiert werden.

Die Kopie sollte mit einer zweiten Synchronisation, Dateianzahlen, Stichproben und bei kritischen Daten mit Prüfsummen kontrolliert werden. Mit getfacl, getfattr und gezielten Tests lassen sich ACLs und Extended Attributes prüfen. Hardlinks müssen anhand von Link-Anzahl und Inode-Beziehungen kontrolliert werden.

Mount-Konfiguration und Systempartitionen

Die UUID des neuen Dateisystems wird so ermittelt:

sudo blkid /dev/TARGET_DEVICE
sudoedit /etc/fstab

Ein möglicher Eintrag für eine Datenpartition lautet:

UUID=ZIEL-UUID /daten ext4 defaults 0 2

Vor dem Neustart sollte die Konfiguration mit sudo mount -a getestet werden. Bei einer Systempartition ist der Ablauf anspruchsvoller: Ein Rettungsmedium kann nötig sein, die Zielpartition muss an der richtigen Stelle eingehängt werden, und /etc/fstab, initramfs sowie Bootloader müssen zur neuen UUID und Dateisystemart passen. Die konkreten Befehle für initramfs und Bootloader hängen von Distribution und Firmwaremodus ab. Nach der Umstellung sind Testboot, Mounts, Netzwerk, Dienste und Protokolle zu prüfen.

Vergleich mit Alternativen

ext4 ist für allgemeine Linux-Systeme meist die konservative Wahl: Es ist breit unterstützt, gut dokumentiert und in vielen Rettungsumgebungen verfügbar. XFS eignet sich häufig für große Dateien, große Dateisysteme und skalierende Serverworkloads. Btrfs bietet Copy-on-Write, Snapshots und Prüfsummen, verlangt aber ein anderes Betriebs- und Backupverständnis.

Die Auswahl sollte sich an Supportstatus, Workload, Betriebswissen, Backupstrategie und Distributionsunterstützung orientieren. Ein moderneres Dateisystem übertrifft nicht unter identischen Bedingungen automatisch jede historische ReiserFS-Stärke. Entscheidend ist, ob die gesamte Betriebsumgebung langfristig wartbar und wiederherstellbar bleibt.

Typische Fehlerbilder und sichere Reaktionen

mount meldet einen unbekannten Dateisystemtyp

Wahrscheinlich fehlt dem laufenden Kernel der ReiserFS-Treiber oder die Rettungsumgebung ist zu neu beziehungsweise ohne ReiserFS-Unterstützung gebaut. Es darf keinesfalls formatiert oder initialisiert werden. Stattdessen sollte ein vertrauenswürdiges Rettungssystem mit Leseunterstützung verwendet und der Datenbestand auf ein aktuelles Dateisystem kopiert werden.

reiserfsck findet Inkonsistenzen

Mögliche Ursachen sind ein unsauberes Herunterfahren, I/O-Fehler, defekte Hardware oder beschädigte Metadaten. Das Dateisystem muss ausgehängt werden. Danach sind SMART-Werte und Systemprotokolle zu prüfen. Zuerst sollte ein Abbild erstellt und eine Prüfung mit --check durchgeführt werden. Schreibende Reparaturen dürfen erst nach Bewertung ihrer Folgen und mit einem Wiederherstellungsplan erfolgen.

Nach der Migration fehlen Rechte, ACLs oder Hardlinks

Ursachen sind oft fehlende rsync-Optionen, eine Kopie ohne Root-Rechte oder Attribute, die das Ziel nicht unterstützt. Die Kopie sollte mit -aHAXx --numeric-ids wiederholt und mit getfacl, getfattr sowie Link- und Dateivergleichen kontrolliert werden. Die alte Quelle bleibt erhalten, bis die Abnahme abgeschlossen ist.

Das System startet nach einer fstab-Änderung nicht

Häufig sind UUID, Mountpoint oder Dateisystemtyp falsch. Über ein Rettungssystem kann die Konfiguration korrigiert werden. Die UUID muss mit blkid verglichen werden; danach sollte mount -a vor dem nächsten Neustart erfolgreich laufen. Bei Systempartitionen sind zusätzlich Bootloader und initramfs zu kontrollieren.

Prüfungssicht: wichtige Merksätze

• ReiserFS ist ein historisches Linux-Journaling-Dateisystem, keine empfehlenswerte Grundlage für neue Systeme.
• Journaling verbessert die Wiederherstellung der Dateisystemkonsistenz, ist aber kein Backup.
• B-Bäume organisieren Metadaten und Verzeichniseinträge effizient.
• Tail Packing spart bei kleinen Dateiresten Platz, kann aber Datenrettung und forensische Analyse erschweren.
• LVM und RAID sind Schichten unterhalb des Dateisystems und keine ReiserFS-Funktionen.
• reiserfsck darf nicht auf einem eingehängten, beschreibbaren Dateisystem ausgeführt werden.
• Vor schreibender Reparatur sind ein Abbild und eine unabhängige Datensicherung erforderlich.
• Die Migration erfolgt normalerweise nicht In-Place, sondern über ein neues Ziel-Dateisystem und eine validierte Kopie.
• Bei der Datenkopie müssen neben Dateien auch Rechte, ACLs, Extended Attributes, Hardlinks und numerische Besitzer berücksichtigt werden.

Für die weitere Beschäftigung mit dem Thema steht die interne Übersicht ReiserFS-Dateisystem zur Verfügung.