Wozu haben moderne Laptops eigentlich einen mSATA-Slot? – SSD RAID 1 mit BTRFS für das Laptop

So schnell SSDs auch sind – so schnell sind sie auch voll. Oder so ähnlich. So geschehen mit der 300 GB Intel SSD 320 in einem ThinkPad T520. Die SSD durch eine größere austauschen wäre eine Möglichkeit gewesen. Doch wozu haben moderne Laptops eigentlich einen mSATA-Slot? In dem sogar eine Weile schon eine 30 GB mSATA SSD von Intel lief, auf dem das Debian GNU/Linux residierte. Ein Preis-/Leistungsvergleich brachte mich schnell auf eine Crucial m500 mSATA SSD. Vielleicht nicht die schnellste, aber zuverlässig. Und günstig. Warum also nicht gleich 480 GB? 

So klein und doch schon 480 GB

Ob nun aus dem Anlaß des Füllstandes der SSD oder aus dem reinen Interesse „Geht das denn überhaupt?“: Ich nahm mir vor, wichtige Daten und das Betriebssystem gleich als BTRFS RAID 1 auszulegen. BTRFS das ist die große Dateisystem-Hoffnung im Linux-Umfeld oder mit den Worten des bekannten Entwicklers Andrew Morton: „I am hoping that BTRFS will save us“.

BTRFS – oder B-Tree FS, da es aus B-Bäumen besteht, oder Butter FS wie in Brot und Butter – ist ein Copy On Write-Dateisystem mit Prüfsummen, Snapshots, Volume-Verwaltung, On the fly-Komprimierung, Online-Defragmentierung, RAID und Einigem mehr. Mit Hilfe der Prüfsummen und des eingebauten RAID-Supports kann BTRFS Bitfehler reparieren, solange eines der Laufwerke noch eine korrekte Kopie hat.

Weitere spannende Funktionen sind im Test oder in Entwicklung wie: Send/Receive, zum pfeilschnellen Übertragen von Schnappschuss-Differenzen auf ein anderes Laufwerk, auch übers Netzwerk, Offline- und Online-Deduplizierung sowie Hot Data Tracking, das beim Mischbetrieb mit Festplatten und SSDs häufig genutzte Daten auf die SSDs schiebt.

Hört sich gut an? Einen Nachteil hat die Sache aber noch: An sich ist BTRFS weiterhin im Beta-Stadium, auch wenn einige Linux-Distributoren wie SUSE und Oracle begrenzten Support bieten. Aber sei es drum: BTRFS läuft seit fast 3 Jahren auf besagtem Laptop und als RAID 1 für einige lokalen Daten auf einer Workstation und auf einigen anderen Maschinen. Und es ist ja auch wichtig, dass es irgendjemand testet, auch wenn das immer wieder mal einige Scherze von Kollegen einbringt.

Für das initiale Secure Erase und das reibungslose Befüllen der neuen SSD bot sich ein mSATA-Adapter auf eSATAp sowie USB 2/3 an. Gesagt, getan, mein Vorgehen im Groben:

Eine externe mSATA SSD zum Mitnehmen? Warum eigentlich nicht?

• Secure Erase, um den Hersteller-Crypto-Schlüssel der SSD durch einen zufälligen Schlüssel zu ersetzen.
• Neue SSD partitionieren.Eine Boot-Partition, EFI-Partition – falls ich nochmal einen Versuch wage, das Laptop via EFI zu booten –, Rest als logisches Laufwerks-Management (LVM).
• Anlegen der logischen Laufwerke: Je eines für das Betriebssystem, die gespiegelten Daten (/home) und für ungespiegelte Daten nur auf neuen mSATA-SSD (/daten).
• Das Laufwerk mit dem Debian GNU/Linux-System wollte ich komplett neu machen. Anlegen des Dateisystems für das Betriebssystem:
  mkfs.btrfs -d raid 1 -m raid1 /dev/sata/debian /dev/msata/debian
• Das Betriebssystem übertrug ich dann mit rsync -aAHXS usw. BTRFS Send/Receive hebe ich mir für die Zukunft auf.
• Kopieren der Daten von /home, die ich nicht spiegeln möchte auf das neue ungespiegelte Laufwerk. Von SSD zu SSD also schön flink
• Beim Verkleinern von /home blieb der verwendete 3.14er-RC-Kernel allerdings hängen – kein Datenverlust, jedoch dennoch ein Bug
• Alternativmethode: Neu-Anlegen des Dateisystems für /home auf der neuen mSATA-SSD und Kopie via rsync und späteres Erweitern auf RAID 1:
  btrfs device add /dev/sata/home-neu /mnt/home-neu sowie btrfs balance start -mconvert=raid1 -dconvert=raid1 – nett 🙂
• Ha! Und dann noch noch das Booten. Damit BTRFS die Laufwerke eines Mehr-Geräte-Dateisystems finden ist ein Aufruf von btrfs device scan erforderlich und dann gab es da noch ein weiteres Problem mit der InitRAMFS. Ein Hook-Skript mit den erforderlichen Befehlen löste das Problem für mich.

Bislang läuft das mit dem Linux Kernel 3.14 hervorragend. Und es ist ein beruhigendes Gefühl, für die Konsistenz der Daten einen Nachweis bekommen zu können:

So ein Datenschrubben läuft mit einer stattlichen Geschwindigkeit – siehe die Spalte bi für Block In in KByte-Blöcken – die Intel SSD 320 ist eine SATA-300 SSD und das ThinkPad macht über den mSATA-Slot auch nur SATA-300, sonst würde das wahrscheinlich nochmal schneller gehen, was aber für einen typischen Desktop-Workload mit viel Random I/O kaum eine Rolle spielen dürfte:

Wenn dann ein Befehl noch die Abwesenheit anderweitiger Fehler dokumentiert – kommt das natürlich noch besser:

Das Ergebnis: 780 GB rohe SSD-Kapazität, teilweise selbstheilend redundant, was natürlich die nutzbare Kapazität dann wieder reduziert. Und das gute Gefühl, beim Praxistest für BTRFS mitzuhelfen. Im Server-Einsatz mit wichtigen, nicht anderweitig gespeicherten Firmen-Daten wäre ich dennoch noch vorsichtig. Mein Langzeit-Test dient auch dazu, für den zukünftigen Produktiv-Einsatz von BTRFS Erfahrungen zu sammeln. Ein gutes Backup ist natürlich so oder so immer empfehlenswert.

Martin Steigerwald

Martin Steigerwald beschäftigt sich seit Mitte der 90er Jahre mit Linux. Er ist langjähriger Autor von Artikeln für verschiedene Computer-Magazine wie die LinuxUser (linuxuser.de) und das Linux-Magazin (linux-magazin.de). Seit Herbst 2004 ist er als Trainer für Linux-Themen bei Proact Deutschland in Nürnberg tätig.