In diesem Artikel beschreibe ich den Umzug von openSUSE 12.3 auf eine SSD. In meinem Fall gehe ich auf die Samsung SSD 840 Pro (512 GB) ein. Die Anleitung funktioniert auch mit anderen SSDs von der Samsung Pro-Serie.

Wichtig: Die Befehle im Artikel müssen als root ausgeführt werden. Hier ist die Partitionszuordnung nur als Beispiel anzusehen und muss an die Gegebenheiten vom eigenen System angepasst werden.

Inhalt:

• Prolog
• Aktivierung der Host Protected Area (HPA) / Stichwort: Over-Provisioning
• Partitionierung / Dateisystem
• Umzug von openSUSE
• Anpassung an die neue Umgebung

Prolog

Meine 5 Jahre alte Festplatte (Samsung HD753LJ / 750 GB) hatte nicht nur Windows XP überstanden, sondern auch die Anfänge mit openSUSE und diverse andere Linux-Distributionen, die ich zum Test auch heute noch nebenbei installiert habe. Irgendwann wollte ich ein Kernelmodul unter openSUSE bauen. Dabei kam es immer an derselben Stelle zu einem Lesefehler und der Kompiliervorgang wurde abgebrochen. Leider hat mir das S.M.A.R.T.-Monitoring-Tool nicht gutes mitzuteilen und nach einer Überprüfung der Festplatte via fsck kamen auch weitere fehlerhafte Blöcke zum Vorschein. Herbe Datenverluste waren in meinem Fall nicht zu erwarten, obwohl einige Dateien unwiederbringlich verloren gegangen sind. Zum Glück war nur die root-Partition betroffen und konnte die fehlerhaften Dateien durch die Reinstallation des betreffenden RPM-Pakets wiederherstellen. Meine home-Partition war noch in Ordnung. Im Notfall habe ich noch ein aktuelles Backup. Dennoch ist mein Vertrauen in die Festplatte stark gesunken. So kam prompt die Entscheidung eine SSD zu holen, die ich vor langer Zeit eingeplant habe. Zu diesem Thema habe ich mich intensiv auseinander gesetzt und mich letztendlich für die Samsung SSD 840 Pro mit 512 GB entschieden.

Aktivierung der Host Protected Area (HPA)

Kurz vorweg: Was ist eigentlich HPA bzw. Over-Provisioning?
Das ist für das Betriebssystem ein unsichtbarer Datenbereich (Spare Area). Sie dient dazu Lese- und Schreibvorgänge zu optimieren (Read-Modify-Write), Ersatz für fehlerhafte Blöcke (Badblocks Replacement), optimale Ausnutzung der Speicherzellen (Wear-Leveling).

Bei der Samsung SSD Pro-Serie ist das HPA-Feature werksseitig deaktiviert. Sie lässt sich ohne Probleme aktivieren und wird ausdrücklich empfohlen. Eine nachträgliche Aktivierung von HPA ist mit Datenverlust verbunden. Daher sollte man sich mit diesem Thema früh genug auseinandersetzen. Bei einer nagelneuen SSD ist es ein guter Zeitpunkt das HPA-Feature zu aktivieren und sich über die Größe der Spare Area Gedanken zu machen.

Wie groß darf denn die Spare Area sein?
Es gibt je nach Nutzung unterschiedliche Werte, die lediglich auf Empfehlungen basieren. Wir sprechen hier im Bereich von 7% (Empfehlung von Samsung) bis 27% (Empfehlung von Intel) des reservierten Datenbereichs. Für meine Zwecke habe ich die Empfehlung von Samsung (7%) modifiziert und nochmal 3% daraufgelegt. Meines Erachtens sind 10% Spare Area mehr als genug. 10% von 512 GB entspricht 51,2 GB. Also, habe ich am Ende 460,8 GB nutzbaren Datenbereich.

Jetzt müssen wir herausfinden, auf welchem Device-Pfad die SSD zugeordnet ist:

hwinfo --disk | grep -E 'Model|Device File:'

Die Ausgabe von meinem System:

Model: "Samsung SSD 840"
Device File: /dev/sda
Model: "SAMSUNG HD753LJ"
Device File: /dev/sdb

Hier sehen wir, dass der Device-Pfad unterhalb des Modellnamen „Samsung SSD 840“ /dev/sda lautet. Wenn euer Device-Pfad der SSD abweicht, bitte bei den nachfolgenden Befehlen an eure Gegebenheiten anpassen.

Nun lassen wir die Anzahl der Sektoren von der SSD ausgeben:

hdparm -N /dev/sda | sed -e '/sectors/!d' -e 's@.*/\(.*\),.*@\1@'

Ausgabe:

1000215216

10% von der o.g. Zahl ist: 100021521,6. Dann runden wir auf eine Ganzzahl auf: 100021522. Und nun ziehen wir von der Summe den berechneten reservierten Datenbereich ab und im Ergebnis haben wir die Summe der Sektoren für den nutzbaren Datenbereich:
1000215216 – 100021522 = 900193694

Jetzt fragen wir die SSD ab, ob HPA werksseitig deaktiviert ist oder bereits aktiviert wurde:

hdparm -N /dev/sda

Die Ausgabe ist:

/dev/sda:
 max sectors   = 1000215216/1000215216, HPA is disabled

In der o.g. hdparm-Ausgabe bedeutet es, dass das HPA-Feature deaktiviert ist. Erkennbar an „HPA is disabled“. Sollte es hier bereits aktiviert sein, dann liegt die Entscheidung an euch, ob ihr den Wert übernimmt oder den Wert wie nachfolgend abändert.

Nun aktivieren wir via hdparm das HPA-Feature und legen die Summe der Sektoren für den nutzbaren Datenbereich fest:

hdparm -Np900193694 --yes-i-know-what-i-am-doing /dev/sda

Beim nächsten Aufruf von „hdparm -N /dev/sda“ sehen wir nun folgende Ausgabe, in der auch das HPA-Feature aktiviert ist:

/dev/sda:
 max sectors   = 900193694/1000215216, HPA is enabled

Falls HPA in eurer Ausgabe weiterhin deaktiviert ist, dann empfiehlt es sich an dieser Stelle den Rechner einmal neuzustarten und dann die Abfrage erneut auszuführen.

Partitionierung / Dateisystem

Jetzt kommen wir zur Partitionierung der SSD und die Festlegung eines geeigneten Dateisystem für die SSD. Ich empfehle, die Partitionierung mit dem YaST-Partitionierer oder mit gparted durchzuführen. Beide Tools sind selbsterklärend und leicht zu bedienen. Es steht jedem frei, auch andere Partitionierer wie z.B. fdisk, sfdisk, gdisk, usw. zu nutzen.

Was ist bei der Partitionierung der SSD zu beachten?
In der Regel kann man nach Belieben die Partition einteilen. Bitte achtet darauf, dass ihr den Boot-Flag von der root- bzw. boot-Partition setzt und eure Partition(en) nicht zu klein dimensioniert, sonst habt ihr beim Umzug von openSUSE ein Problem.

Ist es klug auf der SSD eine Swap-Partition anzulegen?
Grundsätzlich ist es zu empfehlen, auf der SSD eine Swap-Partition anzulegen. Über die Größe der Swap-Partition scheiden sich heute noch die Geister. Wenn ihr unsicher seid, dann übernehmt einfach die Größe der Swap-Partition von der alten Festplatte. Falls ihr das Suspend2Disk-Feature benutzt, solltet ihr die Größe des Swap nach dem Arbeitsspeicher richten und nochmal 25-50 % dazurechnen.

Welches Dateisystem arbeitet am Besten mit der SSD zusammen?
Es ist wichtig ein Dateisystem zu wählen, welches vom Kernel unterstützt wird und das TRIM-Kommando direkt an die SSD absetzen kann. Ab Kernel 3.7 werden die Dateisysteme ext4, btrfs, JFS wie auch XFS die direkte TRIM-Funktion unterstützen. Wenn man ein Dateisystem gewählt hat, dass die TRIM-Funktion vom Kernel nicht unterstützt, dann gibt es die Möglichkeit via Cronjob den Trim-Befehl „fstrim /“ in einem bestimmten zeitlichen Abstand ausführen zu lassen. Der bedeutende Nachteil bei der Cronjob-Variante ist, dass der Trim-Befehl unabhängig der Auslastung des Systems ausgeführt wird und die Performance zum Teil erheblich beeinträchtigt. Daher ist die direkte Kernelunterstützung des TRIM-Kommando vorzuziehen, da die Ausführung von Kernel-TRIM nach der geringsten Systemauslastung gestartet wird und gezielt die freizumachenden Blöcke an die SSD übermittelt.

Soll ich das Journaling vom Dateisystem bei einer SSD aus Gründen der Performance deaktivieren?
Ganz klar: NEIN. Wer die Journaling-Funktion vom Dateisystem deaktiviert, ist man genauso unsicher unterwegs wie in einem Auto mit absichtlich deaktiviertem ABS und ESP. Es kann eine Zeit lang gut gehen, wenn aber wegen der fehlenden Sicherung ein Unfall passiert, dann kann es böse enden. Das ist zu dem Dateisystem eine weitere Sicherung, die man besser nicht ausschalten sollte, sonst riskiert man ein nicht-reparierbares inkonsistentes Dateisystem. Es stimmt, dass man die Performance bei deaktivierten Journaling nochmal steigern kann, ist aber aus den angeführten Gründen absolut nicht zu empfehlen.

Da ich persönlich sehr viel mit openSUSE arbeite und der Bedarf an Speicherplatz immer weiter gestiegen ist, habe ich die Partitionierung und Formatierung meiner SSD wie folgt vorgenommen:

/dev/sda1 = root-Partition / = 200 GB (ext4) + Boot-Flag
/dev/sda2 = home-Partition /home = 200 GB (ext4)
/dev/sda3 = swap-Partition = Rest 30 GB

Umzug von openSUSE

Vor dem Umzug des openSUSE-Systems notiert ihr euch, welche Partitionen in eurem laufenden openSUSE-System eingebunden sind.

mount | grep '^/dev'

Die Ausgabe ist zum Beispiel:

/dev/sdb1 on / type ext4 (rw,relatime,data=ordered)
/dev/sdb2 on /home type ext4 (rw,relatime,data=ordered)

Nach erfolgreicher Partitionierung und Formatierung der SSD kommen wir jetzt nun zum Umzug von openSUSE. Der Umzug eines Linux-System ist gar nicht mal so kompliziert wie viele denken. Jetzt benötigen wir entweder eine Live-CD, eine Rescue-CD oder man hat ein 2. Linux-System auf dem Rechner installiert. Der Grund ist, dass ein laufendes System schlecht kopiert werden kann und der Zustand des Systems sich ständig verändert und zum Teil auf die Dateien nicht lesend zugegriffen werden kann. Achtet bitte darauf, dass mindestens ein Kernel 3.7 oder höher dabei ist. Wer keine CD brennen möchte und ein USB-Stick hat, empfehle ich den Griff zur SystemRescueCD und geht die kurze Anleitung zur Installation auf dem USB-Stick durch. Falls ihr SystemRescueCD verwendet, wählt im Boot-Menü in jedem Fall den Eintrag „D“ oder „E“ als alternativen Kernel. Der alternative Kernel ist in der Version 3.10.x und bringt die beste Unterstützung der TRIM-Funktion der meisten Dateisystemen für die SSD out-of-the-box mit.

Nach dem Booten in ein anderes Live-System öffnen wir ein Terminal/Konsole und meldet uns via su als root an.

Bevor wir loslegen, testen wir erst mal, ob die Tools (fdisk, rsync) auf dem System vorhanden sind, die wir später benötigen. Es wird der entsprechende Pfad zu dem Tool angezeigt:

which fdisk rsync

Sollte ein Tool im Live-System nicht verfügbar sein, installiert man sich das Tool nach oder nimmt ein anderes Live-System.

Eine Liste aller Partitionen kann wie folgt jederzeit abgefragt werden:

fdisk -l

Im Live-System wechseln wir jetzt ins /tmp Verzeichnis, denn dort findet unser Umzug statt:

cd /tmp

Dann erstellen wir 2 Verzeichnisse:

mkdir NEW OLD

Nun müssen wir die alte Partition von der Festplatte in OLD und die neue Partition von der SSD in NEW einbinden. Zudem habe ich die Mount-Option für die SSD gleich auf „noatime,nodiratime,discard“ gesetzt. Aus Gründen der Performance habe ich noatime wie auch nodiratime gesetzt, sowie den Kernel-TRIM via discard eingeschaltet. Wir fangen zuerst mit der root-Partition an:

mount /dev/sdb1 /tmp/OLD
mount -o noatime,nodiratime,discard /dev/sda1 /tmp/NEW

Nachher binden wir alle weiteren Partitionen in OLD und NEW ein. Wer noch weitere Partitionen für z.B. /home, /var, /tmp, /srv, usw. hat, müssen diese ebenfalls eingebunden werden. Bei mir jedenfalls ist es die home-Partition.

Nun wechseln wir nach OLD:

cd /tmp/OLD

Dann kopieren wir das entsprechende Verzeichnis für den Mountpunkt zur neuen Partition. Ich verwende hier gerne das Tool rsync. Dabei bleiben alle Attribute wie Userzuordnung, Gruppenzuordnung, Rechte und spezielle Attribute erhalten. In meinem Fall kopiere ich nur das home-Verzeichnis:

rsync -auxlPRAXSHD --delete --include="home/" --exclude="*" . /tmp/NEW

An dieser Stelle binden wir jetzt alle fehlenden Partitionen ein. In meinem Fall nun die home-Partition:

mount /dev/sdb2 /tmp/OLD/home
mount -o noatime,nodiratime,discard /dev/sda2 /tmp/NEW/home

Die beiden o.g. Beispiele können auch angewendet werden, wenn man auf der alten Festplatte 4 Partitionen hat und auf der SSD nur 2 Partitionen verwenden möchte oder umgekehrt, dass man auf der SSD weiter aufteilen möchte. Denkbar ist auch ein Hybrid-System z.B. die root-Partition ist auf der SSD und die Userdaten wie die home-Partition auf einer separaten Festplatte. Es gibt tatsächlich weitaus mehr Kombinationsmöglichkeiten.

Jetzt geht ans Eingemachte. Nun starten wir endgültig den Kopiervorgang und kann je nach Umfang der Daten eine ganze Weile dauern:

rsync -auxlPRAXSHD --delete . /tmp/NEW

Wer möchte, kann mit einem Dateimanager vom Live-System sich das Verzeichnis /tmp/NEW oder im Terminal/Konsole anschauen:

cd /tmp/NEW
ls -l

Anpassung an die neue Umgebung

Nun müssen wir noch 4 weitere Anpassungen vornehmen. Das bedeutet, dass wir die Datei /etc/fstab und den Bootloader (hier: Grub2) in /etc/sysconfig/bootloader, /boot/grub2/device.map wie auch /boot/grub2/grub.cfg anpassen. Zudem werden wir Grub2 in das Master-Boot-Record (kurz: MBR) oder in die Partition von der SSD installieren. Zum Abschluss der Änderungen erstellen wir eine neue Initial-Ramdisk (kurz: initrd), in der die Information zur root-Partition wie auch dessen Dateisystem gespeichert sind und zusätzlich noch das entsprechende Prüfwerkzeug für das Dateisystem beinhaltet.

Wir öffnen nun z.B. mit dem vi-Editor die Datei /etc/fstab als root auf der SSD:

vi /tmp/NEW/etc/fstab

Wir sehen beispielsweise diese Ausgabe:

/dev/disk/by-id/ata-SAMSUNG_HD753LJ_S13UJ1BQ803012-part1 /                    ext4       acl,user_xattr        1 1
/dev/disk/by-id/ata-SAMSUNG_HD753LJ_S13UJ1BQ803012-part2 /home                ext4       acl,user_xattr        1 2
/dev/disk/by-id/ata-SAMSUNG_HD753LJ_S13UJ1BQ803012-part3 swap                 swap       defaults              0 0

Die o.g. Device-Pfade müssen wir nun an die SSD anpassen. Dazu schauen wir auf dem System wie diese lauten und auf die SSD /dev/sda verweisen:

ls -l /dev/disk/by-id/

Ausgabe (gekürzt):

...
lrwxrwxrwx 1 root root  9 21. Sep 03:06 ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B -> ../../sda
lrwxrwxrwx 1 root root 10 21. Sep 00:43 ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 21. Sep 00:43 ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 21. Sep 00:43 ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part3 -> ../../sda3
...

Jetzt ersetzen wir die o.g. Pfad in unserer /etc/fstab Datei:

/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part1 /                    ext4       acl,user_xattr        1 1
/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part2 /home                ext4       acl,user_xattr        1 2
/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part3 swap                 swap       defaults              0 0

Die TRIM-Funktion vom Kernel ist standarmäßig ausgeschaltet und muss über die Mount-Option discard eingeschaltet werden. Aus Gründen der Performance und der Langlebigkeit der SSD empfehle ich die Mount-Optionen noatime wie auch nodiratime zu setzen.

Zum Abschluß sieht das Ergebnis so aus und kann nun abgespeichert werden:

/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part1 /                    ext4       acl,user_xattr,noatime,nodiratime,discard        1 1
/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part2 /home                ext4       acl,user_xattr,noatime,nodiratime,discard        1 2
/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part3 swap                 swap       defaults,discard              0 0

Jetzt kommen wir zur Grub2-Konfiguration. Dazu öffnen wir einmal /etc/grub2/device.map mit dem vi-Editor:

vi /tmp/NEW/boot/grub2/device.map

Die Ausgabe als Beispiel:

(hd0)   /dev/disk/by-id/ata-SAMSUNG_HD753LJ_S13UJ1BQ803012

Und setzten auch hier den neue Device-Pfad:

(hd0)   /dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B

Jetzt öffnen wir auch nochmal die Datei /etc/sysconfig/bootloader mit dem vi-Editor:

vi /tmp/NEW/etc/sysconfig/bootloader

Dort ersetzen wir alle alten Device-Pfade mit der neuen (Bitte auf die Gegebenheiten der Swap-Partition anpassen, hier als Beispiel part3):

...
DEFAULT_APPEND="   resume=/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part3 splash=silent quiet showopts"
XEN_KERNEL_APPEND="   resume=/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAD817211B-part3 splash=silent quiet showopts"
...

Bevor wir das System neustarten, müssen wir einmal eine neue Grub2-Konfiguration erzeugen lassen und den Bootloader-Code z.B. in den MBR der SSD neuinstallieren. Dazu werden wir erst die Verzeichnisse vom Live-System /dev, /proc, /sys in das root-Verzeichnis /tmp/NEW der SSD einbinden:

mount --bind /dev /tmp/NEW/dev
mount --bind /proc /tmp/NEW/proc
mount --bind /sys /tmp/NEW/sys

Dann chrooten wir in das System:

chroot /tmp/NEW /bin/bash

Neue Grub2-Konfiguration erzeugen (Hinweis: Es wird noch das alte openSUSE-System von der alte Festplatte miterfasst. Falls man das nicht möchte, muss später nach der Trennung der Festplatte der u.g. Grub2-Befehl nochmal ausgeführt werden):

grub2-mkconfig -o /boot/grub2/grub.cfg

Nun den Bootloader-Code von Grub2 in den MBR installieren (Falls abweichend bitte anpassen):

grub2-install /dev/sda

Nun erzeugen wir sicherheitshalber eine neue Initial-Ramdisk (kurz: initrd) oder mehrere (abhängig von der Anzahl der installierten Kernel):

mkinitrd

Wir sind nun fertig und können jetzt die Chroot-Umgebung verlassen und ins root-Verzeichnis zurückkehren:

exit
cd /

Alle gemounteten Verzeichnisse in /tmp/OLD und /tmp/NEW abkoppeln (Falls abweichend bitte anpassen):

umount /tmp/OLD/home
umount /tmp/OLD
umount /tmp/NEW/home
umount /tmp/NEW/dev
umount /tmp/NEW/proc
umount /tmp/NEW/sys
umount /tmp/NEW

Jetzt kommt der spannende Moment und zwar der Neustart des Systems (Ggfs. müsst ihr im BIOS die Bootreihenfolge nochmal ändern):

reboot

Feedback wie auch Erfahrungsberichte auf der Basis dieser Anleitung ist erwünscht.

War dieser Artikel für dich hilfreich und/oder konnte dein Problem lösen? Wie wäre es mit einer kleinen Spende (Flattr, Paypal oder Überweisung) für den Erhalt des Blogs und zur Förderung weiterer interessanter Artikel? Zudem ist mit jeder Spende gewährleistet, dass der Blog werbefrei ist und auch in Zukunft werbefrei bleiben wird. Ich sage schon mal an alle Spendern herzlichen Dank.