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? 

Crucial m5 mSATA SSD

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:

Delock mSATA auf eSATA und USB2 2/3 Adapter

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 Consultant für solide Server-Infrastruktur auf Linux-Basis und als Trainer für Linux-Themen bei der teamix GmbH (teamix.de) in Nürnberg tätig.

 
Kommentare

Hi,

gibt es denn schon einen Zwischenbericht?

Beste Grüße
Dominic

Martin Steigerwald
Martin Steigerwald

Hallo Dominic,

ich hab einen im Sinn, bin aber noch nicht dazu gekommen, und da ich jetzt gerade noch zwei Wochen Schulungen halte, kurz: Läuft! Einmal hatte ich auf der mSATA SSD von Crucial ein paar Prüfsummen-Fehler, die dank RAID 1 ein btrfs scrub reparariert hat. Meine Vermutung dazu ist, dass die bei einem harten Ausschalten des Systems wegen eines Hängers durch einen teilweise Schreibvorgang aufgetreten sind, denn ich kann mir nicht vorstellen, wo die Crucial mSATA SSD Kondensatoren drauf haben sollte, wie sie die Intel SSD 320 hat, um in einem solchen Fall noch nicht geschriebene Daten noch auf Flash zu sichern. Der Hänger hatte mit BTRFS zu tun. Die Kernel-Versionen 3.15 und 3.16 hatten da ein Problem, das ab 3.16.2 und 3.17 behoben ist.

Im Zwischenbericht, vielleicht in der Woche vor Weihnachten, würde ich das in etwas mehr Detail beleuchten. Ich müsste auch die Befehlsausgaben und Protokoll-Einträge dazu noch irgendwo haben.

Ciao,
Martin

Hinterlassen Sie einen Kommentar

Time limit is exhausted. Please reload CAPTCHA.