Selbst preisgünstige SSDs bieten mehr Speicherplatz, als eine Linux-Root-Partition benötigt. Der verbleibende Platz kann als Festplatten-Cache die Leistung steigern.

Damit ein langsames Starten der Anwendungen nicht den Spaß an einer schnellen CPU trübt, ist es anzuraten, die Systempartition, die unter Linux lediglich 100 bis 200 MByte groß ausfallen muss, auf einer SSD anzulegen. Selbst günstige 256 oder 512 MByte große SSDs sind mit der Systempartition noch nicht voll belegt. Der verbleibende freie Speicher genügt zwar nicht mehr für eine sinnvoll dimensionierte Home-Partition, reicht jedoch als Cache für eine große langsamere Festplatte.

Ein Cache hält die häufig gebrauchten Daten im schnellen SSD-Speicher. Schreib- und Lesezugriffe erfolgen daher oft in SSD-Geschwindigkeit, trotzdem steht das Speichervolumen der größeren Festplatte zur Verfügung. Zwei ausreichend große Festplatten und zwei SSDs mit 256 bis 512 MByte genügen so für ein leistungsstarkes, durch Redundanz gesichertes System mit ausreichend Speicherplatz (Abbildung 1). Bei dieser Lösung teilen sich Home- und Root-Partition die Lese- und Schreibbandbreite einer SSD, doch bei einem typischen Arbeits-PC fällt das kaum ins Gewicht.

Abbildung 1: Selbst preisgünstige SSDs bieten mehr Platz, als eine gut dimensionierte OpenSuse-Root-Partition belegt. Wir zeigen, wie sich der restliche Platz als Cache für ein als RAID 1 ausgelegtes Home nutzen lässt.

Den Nutzen einer Doppelung von Speichergeräten per RAID 1 erläuterten die OpenSuse-Tipps in LU 01/2026 [1]. Gespiegelte Daten sorgen zusammen mit den Checksummen des von Suse präferierten Btrfs-Dateisystems für höchstmögliche Datensicherheit. Tritt in einem Spiegel-Set des RAIDs ein Datenfehler auf, korrigiert das System die anhand der Checksummen identifizierbaren fehlerhaften Daten automatisch aus der fehlerfreien Hälfte.

Das Einrichten eines Festplatten-Caches beherrschen allerdings weder der bei Tumbleweed eingesetzte klassische YaST-basierte Installer noch der neue webbasierte Leap-16.0-Installer (Abbildung 2). Zum Glück lassen sich Cache-Partitionen später im laufenden System hinzufügen, sofern die zu beschleunigenden Partitionen zu einem LVM-Verbund gehören.

Abbildung 2: Etwas versteckt bietet der neue Installer in der Zeile Details die Möglichkeit, vorgeschlagene Partitionen zu löschen oder deren Größe anzupassen.

Das Ausklappmenü hinter Details in der Rubrik Speicherung gestattet es, für unser Beispiel-Layout aus Abbildung 1 die Auslagerungspartition zu löschen und die Root-Partition auf eine Größe zu begrenzen, die auf der SSD noch Platz für einen Festplatten-Cache lässt. Abbildung 3 zeigt das entsprechende Partitionslayout im grafischen Werkzeug Gparted.

Abbildung 3: Nach der Installation enthält die erste SSD im Rechner lediglich eine kleine UEFI-Startpartition, die Btrfs-Root-Partition (1) sowie nicht partitionierten Platz für den Cache. Ein Rechtsklick auf Letzteren erzeugt daraus eine unformatierte Partition (2).

Bestehende Installationen, die kein LVM für das Home nutzen, lassen sich umwandeln, sofern eine freie Festplattenpartition in der Größe der Home-Partition vorhanden ist. Erstellen Sie zuerst ein LVM mit einem leeren logischen Volume data1 aus dieser Partition. Nach dem Kopieren der Daten aus dem Home löschen Sie das alte Home und fügen dessen Partition dem LVM als logisches Volume hinzu (data2).

Das weitere Vorgehen, insbesondere das Hinzufügen der Cache-Partitionen, gelingt dann wie im Folgenden beschrieben. Eine Neuinstallation sollte als simples Setup in eine SSD-Partition starten, die wie in Abbildung 2 nicht die ganze SSD belegt.

Richtige Einteilung

Per Rechtsklick legt Gparted im freien Speicher auf der ersten SSD /dev/sda eine weitere Partition vom Dateisystemtyp nicht formatiert an. Sie sollte 100 bis 200 MByte groß ausfallen. Die jetzt hinzugefügte Cache-Partition darf von 64 GByte aufwärts den Rest des freien Platzes auf der SSD belegen. Bei NVMe-SSDs heißt die Gerätedatei der ersten SSD im Rechner übrigens /dev/nvme0 statt /dev/sda.

Dann gilt es, die Partitionstabelle des Laufwerks mit dem Root-Dateisystem auf die leer gelassene zweite SSD zu kopieren (vergleiche Abbildung 1). Alle folgenden Befehle zur Partitionsbearbeitung erfordern Root-Rechte. Das Kommando aus der ersten Zeile von Listing 1 legt die Plattenaufteilung von sda in einer temporären Textdatei ab. In dieser Datei entfernen Sie mit einem Texteditor die letzte Spalte UUID.

# sfdisk /dev/sda -d >/tmp/sda.txt
# sfdisk /dev/sdb < /tmp/sda.txt
# btrfs device add /dev/sdb1 /
# btrfs balance start -dconvert=raid1 -mconvert=raid1 /

Sfdisk ist dafür ausgelegt, eine Partitionstabelle eins zu eins zu kopieren, doch UUIDs sollen systemweit eindeutig ausfallen. Nach dem Entfernen erzeugt Sfdisk neue, eindeutige UUIDs, sobald der Befehl aus der zweiten Zeile in Listing 1 die Partitionsaufteilung der ersten SSD auf die noch leere zweite kopiert. Bei NVMe-basierten SSDs ersetzen Sie sda durch nvme0 und sdb durch nvme1. Dabei ist Vorsicht geboten: Überschreiben Sie das falsche Speichergerät, sind die Daten dort verloren oder zumindest schwierig wiederherzustellen. Nehmen Sie Gparted zu Hilfe, um die bestehende Systempartition und die noch leere SSD für die Datenspiegelung zuverlässig zu identifizieren.

Das Kommando aus der dritten Zeile von Listing 1 fügt dem Root-Dateisystem die eben mit Sfdisk erstellte Partition als zweites Speichergerät hinzu. Anschließend ordnet der Befehl aus der letzten Zeile die Daten (-dconvert) und internen Metadaten von Btrfs (-mconvert) in RAID-1-Manier an. Dafür muss das System die bestehenden Daten auf das neue Speichergerät kopieren – bei SSDs immerhin nur eine Frage von Minuten statt von Stunden.

Nach dem Upgrade der Root-Partition zum sicheren RAID 1 soll eine neue Partition für das Home in gleicher Qualität entstehen. Da sie auf einer langsamen Festplatte liegt, gilt es, sie zusätzlich noch durch SSD-Caches zu beschleunigen. Die Basis dafür bildet das bewährte Logical Volume Management des Linux-Kernels. Die Grundaufgabe von LVM ist es, mehrere Partitionen zu einem großen Datenpool zusammenzufassen. Wir nutzen es, um große, langsame Festplattenpartitionen mit kleineren, schnellen SSD-Partitionen zu koppeln.

Der Befehl aus der ersten Zeile von Listing 2 erstellt zunächst eine Volume Group mit den zwei Daten- und den zwei Cache-Partitionen als Mitgliedern. Die Device-Namen auf dem eigenen System lassen sich bei Bedarf mit Gparted ermitteln. Die Befehle aus Zeile 2 und Zeile 3 weisen der Volume Group vg0 zunächst die zwei Festplatten-Datenpartitionen hinzu, in Zeile 4 und Zeile 5 folgen die kleineren SSD-Cache-Partitionen. Dass alle nun erfolgreich der Gruppe vg0 zugehören, zeigt eine Ausgabe von Lvs (Listing 3).

# vgcreate vg0 /dev/sda3 /dev/sdb3 /dev/sdc1 /dev/sdd1
# lvcreate -n data1 -l 100%FREE vg0 /dev/sdc1
# lvcreate -n data2 -l 100%FREE vg0 /dev/sdd1
# lvcreate -n data1_cache -l 100%FREE vg0 /dev/sda3
# lvcreate -n data2_cache -l 100%FREE vg0 /dev/sdb3

$ sudo lvs
data1       vg0 -wi-a----- 512,0g
data1_cache vg0 -wi-a-----  32,5g
data2       vg0 -wi-a----- 512,0g
data2_cache vg0 -wi-a-----  32,5g

Bisher sind alle vier Partitionen als Datenpartitionen konfiguriert. Die beiden Kommandos aus Listing 4 wandeln die SSD-Partitionen in Caches für jeweils eine Datenpartition um. Der Befehl lvconvert zeigt zwei Nachfragen, die Sie beide mit y beantworten. Ein sudo lvs listet nach dem Umwandeln der SSD-Partitionen in Caches nur noch zwei Datenpartitionen als cvol (Abbildung 4).

# lvconvert --type cache --cachevol data1_cache --cachemode writeback vg0/data1
# lvconvert --type cache --cachevol data2_cache --cachemode writeback vg0/data2

Abbildung 4: Die Ausgabe von Lvs zeigt nun, dass jedem der zwei logischen Volumes eine SSD-Partition als Cache zugeordnet ist.

Redundanz

Die zwei jetzt vorliegenden logischen Partitionen /dev/vg0/data1 und /dev/vg0/data2 entsprechen funktional gewöhnlichen Festplattenpartitionen wie /dev/sda1. Das Kommando aus der ersten Zeile von Listing 5 formatiert sie mit einem Btrfs-Dateisystem. Die Parameter -m raid1 und -d raid1 sorgen dafür, dass data1 und data2 die Daten und Btrfs-internen Metadaten von Anfang an als RAID 1 spiegeln. Ein balance-Schritt wie beim Umwandeln eines einfachen Dateisystems in ein RAID 1 entfällt.

# lvconvert --type cache --cachevol data2_cache --cachemode writeback vg0/data2
# mount /dev/vg0/data1 /mnt
# btrfs filesystem df /mnt
# sudo chown -R User:User /mnt/User

Das Btrfs-Dateisystem lässt sich nun mit dem Befehl aus Zeile 2 testweise im Verzeichnis /mnt einhängen. Das Kommando aus Zeile 3 sollte in seiner Ausgabe für Data, System und Metadata die Bezeichnung RAID 1 zeigen (Abbildung 5).

Abbildung 5: Bei Btrfs lässt sich die RAID-1-Redundanz für Daten, Metadaten und interne Strukturen separat zuschalten. Einen Komplettausfall eines Laufwerks übersteht das Dateisystem nur, wenn alle Ebenen als RAID 1 ausgelegt sind.

Das jetzige Verzeichnis /mnt ersetzt später /home und braucht daher ein Unterverzeichnis pro Benutzerkonto. Legen Sie diese Verzeichnisse an und verschieben Sie gegebenenfalls alle weiterhin benötigten Daten aus dem jetzigen /home in diese Verzeichnisse. Mit dem Kommando aus der letzten Zeile von Listing 5 setzen Sie den passenden Besitzer und die Gruppe für das gleichnamige Verzeichnis und dessen Inhalt.

Die Fstab (Datei /etc/fstab) steuert, welche Dateisysteme Linux beim Start lädt. Wurde bei der Installation keine separate Home-Partition gewählt, mountet OpenSuse unter /home (zweite Spalte der Fstab) ein Subvolume der Systempartition (subvol=/@/home, vierte Spalte). Um dieses Home-Subvolume durch die neu erstellte Partition mit RAID 1 und Cache zu ersetzen, passen Sie in der Fstab in jener Zeile, in der in der zweiten Spalte der Einhängepunkt /home steht, die UUID (erste Spalte) an.

Den neuen UUID-Wert liefert der Aufruf aus der ersten Zeile von Listing 6. Außerdem ersetzen Sie die subvol-Angabe in der vierten Spalte durch das Schlüsselwort defaults. Bei Leap-Systemen vor 16.0 und bei vor 2025 installierten Tumbleweed-Systemen ist jetzt alles erledigt: Nach einem Neustart hängt das System die neue, dank RAID 1 sicherere und dank SSD-Cache schnellere Partition als /home ein.

# sudo blkid |grep /dev/mapper/vg0-data--btrfs1
# sudo mount /dev/mapper/vg0-data--btrfs1 /home/
# sudo restorecon -R /home

Bei Leap 16.0 und kürzlich installierten Tumbleweed-Systemen schiebt das unter OpenSuse neu eingeführte Sicherheits-Framework SELinux dem einen Riegel vor, um das unbemerkte Unterschieben eines neuen Verzeichnisses als Home zu erschweren. Ein Login als Anwender oder das Starten der grafischen Umgebung würde in diesem Systemzustand nach einem Reboot fehlschlagen. Daher gilt es, vorher die neue Partition mit dem Kommando aus der zweiten Zeile von Listing 6 über das bestehende Home zu mounten. Der Befehl aus der letzten Zeile registriert sie für SELinux als neues Home.

Den Überblick behalten

Der resultierende Systemaufbau ist wesentlich komplexer als einer, bei dem das Root-Dateisystem auf einer Partition liegt und das Home auf einer weiteren. Das macht es schwieriger, im Fehlerfall zu verstehen, welches konkrete (Hardware-)Problem vorliegt.

Das Lsblk-Kommando aus Abbildung 6 hilft dabei, das System auch Monate nach der Einrichtung noch zu verstehen. Es zeichnet einen Baumgraphen der Speichergeräte, ihrer Partitionen sowie der daraus abgeleiteten logischen Partitionen. Die zweite Spalte nennt den Einhängepunkt, die dritte den Dateisystemtyp, die vierte die Größe und die letzte die UUID, wie sie in der /etc/fstab zum Einsatz kommt. Bewahren Sie am besten einen Screenshot dieser Ausgabe als Ausdruck auf, um Fehlermeldungen bei einem nicht mehr startenden System einordnen zu können.

Abbildung 6: Lsblk schlüsselt auf, welche Partitionen mit welchem Dateisystem formatiert sind und unter welchem Mountpoint Sie sie erreichen.

Stellt Btrfs eine Inkonsistenz zwischen Daten und Checksummen fest, schaltet es das betroffene Dateisystem in den Read-only-Modus, um Datenkorruption zu verhindern. Hängt dann die grafische Umgebung, schaltet [Alt]+[Strg]+[F2] auf eine Textkonsole mit Login-Aufforderung, [Alt]+[Strg]+[F7] kehrt zum grafischen Desktop zurück.

Die Konsolenaufrufe findmnt / und findmnt /home zeigen, ob das beschriebene Szenario für das Root- oder Home-Dateisystem eingetreten ist. Beginnt die Spalte OPTIONS der Ausgabe mit ro, lässt sich das abgefragte Dateisystem nicht mehr beschreiben; bei rw ist dagegen alles in Ordnung. Der Befehl sudo journalctl -g "bad csum" durchforstet das System-Log nach Prüfsummenfehlern.

Auf der Konsole lässt sich bei Btrfs ein “degraded RAID” – also eines, bei dem eine Kopie der redundanten Daten fehlt, die andere aber unversehrt vorliegt – einfach mit der Option -o degraded einhängen. Diese Option können Sie auch in die Fstab eintragen. Damit sollte sich das beschädigte, aber bis auf den fehlenden doppelten Boden funktionsfähige RAID normal nutzen lassen, bis Ersatz für die ausgefallene Hardware bereitsteht.

Allerdings spielen aktuelle Versionen von Systemd nicht mit. Sie prüfen trotz gegenteiliger Anweisung in der /etc/fstab das Vorhandensein aller im RAID registrierten Laufwerke. Das System bleibt dabei unbegrenzt lange hängen, wenn es sich um das Root-Dateisystem handelt. Im Fall von Home startet Systemd wenigstens eine Notfallkonsole, die /home-Partition bleibt aber ausgehängt. Systemd-Chefentwickler Lennart Poettering hat den Fehler als “not our bug” klassifiziert, plant also nicht, ihn zu beheben.

Handelt es sich beim ausgefallenen Laufwerk um eine der SSDs, dann dauert es zum Glück nicht lange, das Root-RAID-1-Volume in ein normales Btrfs-Dateisystem ohne Redundanz zurückzuverwandeln. Ist Ersatzhardware vorhanden, lässt es sich wie weiter oben beschrieben zum zweiten Mal zum RAID 1 upgraden.

Rettungsring

Der Downgrade zum normalen Dateisystem ohne Datenspiegelung erfordert allerdings ein externes Rettungssystem wie die Tumbleweed-Rettungs-Disk [2], denn das System startet ja nicht mehr (Abbildung 7). Wählen Sie im Live-System unter Settings | Keyboard als Layout German und öffnen Sie ein Terminal. Dort hängen Sie dann das havarierte RAID mit dem Befehl aus der ersten Zeile von Listing 7 ein. Im Beispiel handelt es sich bei /dev/sda2 um die noch intakte Datenpartition für dieses Dateisystem.

# mount -o degraded /dev/sda2 /mnt
# sudo btrfs balance start -f -mconvert=single -dconvert=single /mnt
# sudo btrfs device remove missing /mnt

Abbildung 7: Ein Systemd-Bug erzwingt, ein Btrfs-RAID nach Ausfall eines der Laufwerke zu einem nicht redundanten Dateisystem herunterzustufen. Das gelingt mit der Tumbleweed-Rettungs-Disk.

Der Aufruf aus der zweiten Zeile von Listing 7 startet die Zurückstufung zum nicht redundanten Dateisystem. Im Allgemeinen dauert das auf SSDs für die vergleichsweise kleine Root-Partition eher Minuten als Stunden. Nach Abschluss des Vorgangs entfernt das Kommando aus der letzten Zeile das noch registrierte, nun aber durch den Defekt verschwundene Laufwerk. Systemd sollte die Systempartition dann beim Start wieder normal einhängen.

Doch bevor Sie das Rettungssystem verlassen, sollten Sie noch den LVM-Verbund wieder in einen benutzbaren Zustand versetzen, in dem die nicht mehr verfügbare SSD als Cache diente. Der Befehl pvdisplay zeigt eine Übersicht der registrierten physischen Partitionen. Existiert dort ein Eintrag PV Name mit dem Attribut [unknown], dann ist eine registrierte Partition nicht verfügbar. Anhand der vorher festgehaltenen Lvs-Ausgabe und der Angabe unter last written to /dev/... lässt sich ermitteln, ob es sich um den Cache für vg0/data1 oder vg0/data2 handelt.

Das Kommando lvconvert --uncache vg0/data-btrfs2 löst die Cache-Zuordnung der zweiten SSD (sdb). Der Befehl vgreduce --removemissing --force entfernt die nicht mehr erreichbare Festplattenpartition aus dem LVM-Verbund. Das Ergebnis sind eine normal einhängbare Home-Partition sowie ein Btrfs-RAID 1 aus einer nach wie vor beschleunigten und einer unbeschleunigten Komponente. Da alle Lese- und Schreibzugriffe parallel stattfinden, bremst das den Plattenverbund insgesamt auf die Performance ohne Cache herunter. Immerhin sollten die Daten intakt geblieben sein.

Angesichts des geschilderten Startverhaltens von Systemd, das die degraded-Option nutzlos macht, ist es am besten, sich mit einem Home in Festplattengeschwindigkeit zufrieden zu geben, bis Ersatz für die ausgefallene SSD vorliegt. Das neue Laufwerk lässt sich dann mit vgextend vg0 /dev/sdb3 wieder der Volume-Gruppe vg0 hinzufügen, nachdem ihm wie beschrieben via Sfdisk die Partitionsaufteilung des intakten Zwillings hinzugefügt wurde. Der geschilderte Lvconvert-Aufruf zum Umwandeln in einen Cache steht ebenfalls erneut an.

Fällt statt einer SSD-Cache-Partition eine am Home beteiligte Datenpartition auf einer Festplatte aus, wird es ungemütlicher. Auch hier bootet das System zunächst in eine Rettungskonsole. Die Daten sind gleichfalls nicht verloren, wie ein manuelles Einhängen mit mount -o degraded /home zeigt. Doch das automatische Mounten beim normalen Systemstartvorgang funktioniert wie erwähnt nicht.

Es bleiben zwei Möglichkeiten: Entweder stufen Sie das RAID 1 der Home-Partition zum einfachen Btrfs-Dateisystem ohne Redundanz herunter, wie für die Root-Partition beschrieben, und nehmen dabei eine lange Umwandlungszeit in Kauf. Oder Sie fügen als pragmatische Zwischenlösung in der /etc/fstab der Zeile der /home-Partition die Option noauto hinzu, und zwar per Komma abgetrennt ohne Leerzeichen hinter dem vorhandenen Schlüsselwort defaults. Auch dann startet das System wieder ohne Rückfall auf die Rettungskonsole. Die Home-Partition müssen sie dann allerdings bei jedem Start vor dem Login als Anwender manuell einhängen.

Liegt eine Ersatzfestplatte vor, dann fügen Sie darauf mit dem Kommando aus der ersten Zeile von Listing 8 die Cache-SSD-Partition und die neu erstellte Partition hinzu. Die Gerätenamen müssen Sie gegebenenfalls anpassen. Anschließend lässt sich mit Lvcreate und Lvconvert ein neues LVM-Volume erstellen, wie bereits beschrieben. Sie sollten es jedoch anders benennen als das bisherige.

# vgextend vg0 /dev/sdb3 /dev/sdd1
# btrfs replace start 1 /dev/vg0/datax /mnt/
# btrfs device add /dev/vg0/datax
# btrfs device add /dev/vg0/datax

Der Aufruf aus der zweiten Zeile des Listings (Details finden sich unter man btrfs-replace) ersetzt das erste alte Volume data1 durch das neu erstellte; bei data2 folgt eine 2 hinter start. Haben Sie als Zwischenlösung das RAID 1 wie beschrieben zu einem Btrfs-Dateisystem ohne Redundanz herabgestuft, verwenden Sie stattdessen die Kommandos aus der dritten und der vierten Zeile.

Fazit

Große Dateien wie RAW-Fotos oder Videos lassen sich am effizientesten auf einer großen Festplatte mit SSD-Cache ablegen und bearbeiten. Auch die Desktop-Umgebung startet schneller, weil ein Cache das Einlesen vieler kleiner Dateien beschleunigt. Es lohnt sich also, wie beschrieben Hand anzulegen. (uba/jlu)