Heuer habe ich mir für meinen PC das OCZ Vertex2 120GB S-ATA-II SSD gekauft und natürlich gleich mein Debian sid darauf umgestellt. Wie ich das gemacht habe, beschreibe ich in diesem Artikel.

Hinweis 1: Ich verwende als neues /-Dateisystem ein EXT4 ohne Journal. Das mag nicht jedermanns Sache sein. Eine Begründung findet sich im Abschnitt „Schritt 2: Erstellen des Dateisystems“.

Hinweis 2: Bei der Partitionierung und der Wahl der Parameter für das von mir verwendete EXT4-Dateisystem bin ich nachträglich nicht 100% zufrieden. Vermutlich habe ich bei der Anlage der Partitionen mit fstab nicht die optimale Geometrie verwendet, habe nicht die performanteste Block-Size für das Dateisystem gewählt, es funktioniert aber alles prima soweit.

Bemerkung: Ob „noop“ oder „deadline“ der bessere IO-Scheduler ist, habe ich nicht substanziell getestet. Ich habe mich für „noop“ entschieden, weil der den Prozessor entlastet und ich Schreibzugriffe in meinem Setup niedrig halte.

Vorbereitungen 1: Einbau

Hardware-Konfiguration: Existierender amd64 PC mit Debian sid auf S-ATA Festplatte. SSD wird via 3,5″ Einbaurahmen (liegt dem Gerät bei) montiert und an S-ATA Port sowie Stromversorgung angeschlossen.

Hinweis: trotz des stolzen Preises liegt dem OCZ Vertex2 kein S-ATA-Kabel bei. Also sicherstellen, dass man eines da hat.

Nach dem Reboot in das System mit HD als Bootmedium und unformatierter, fabrikneuer  SSD wird die HD als /dev/sdb erkannt, die SSD als /dev/sda. Deswegen bezeichne ich meine bisherige Boot-HD als „sdb“, die SSD als geplante neue /-Platte und Bootmedium als „sda“.

Vorbereitungen 2: Agenda

Beabsichtigt ist ein Performance-Gewinn durch Verschieben möglichst grosser Teile des Betriebssystems und häufig benötigter Programme auf die SSD. Bereiche des Dateibaums, die sehr oft modifiziert werden (rotierende Logfiles, Verwaltung des Debian-Paketmanagement, Lock-Dateien und FIFOs) sollen nicht auf die SSD, um die Abnutzung zu minimieren. Zu solchen „stark veränderlichen Dateien“ zähle ich auch alles im Home-Verzeichnis.

Das bisherige System ist einfach alles (/, /boot, /home, /usr, /var usw.) auf einer großen ext3-Partition. Dies soll sich ändern; das angestrebte Layout ist Folgendes:

/ auf der ersten Partition in sda, im Folgenden auch bezeichnet als /-Dateisystem

/var und /home auf sdb

Natürlich werden/proc, /run, /sys und /tmp weiterhin „virtuell dazu-gemountete“ Dateisysteme bleiben.

Durch Umstellen der Bootreihenfolge im BIOS will ich prinzipiell das alte System nochmal booten und im Notfall wieder in Betrieb nehmen können.

Vorbereitungen 3: Übersicht über benötigte Software Werkzeuge

Für den Aufbau des neuen /-Dateisystems  Benötigte Tools: fstab, mkfs.ext4, mount, rsync, chroot, blkid und ein Texteditor.

Als Bootloader soll (wie bisher) grub2 zum Einsatz kommen – derzeit Standard Bootloader in Debian sid. Der existierende grub2 auf sdb soll nicht verändert werden, auf sda soll hingegen grub2 so installiert werden, dass korrekt vom neuen Boot- und Root-Filesystem hochgefahren wird.

Schritt 1: Partitionieren der SSD

Ich erstelle eine Partition auf der SSD. Da ich keine weiteren Partitionen anlegen will, ist das im Prinzip sinnlos, ich könnte auch (wie manche Quellen empfehlen) /dev/sda als Ganzes mit einem Dateisystem ausstatten. Ich bevorzuge aber die klassische Partitionstabelle, weil ich die Kompatibilität auch mit „komischen“ Bootmanagern (dazu zähle ich übrigens grub2) und anderen Werkzeugen (wie dem in Debian integrierten UUID-basierten Update-Management) sicherstellen will. Ich vergebe dadurch allerdings etwas Platz ausserhalb der Partitionsgrenzen.

Ich starte fdisk wie folgt:

fdisk -S 32 -H 32 /dev/sda

Durch das Erzwingen von 32 Sektoren, 32 Heads zwinge ich fdisk in die Verwendung von 32*32=1024 Bytes als Zylindergrösse und damit als Einheit bei der Erstellung von Partitionen. Dies verträgt sich mit der „Maximum Erase Block Size“ der OCZ SSD (Tipp aus [1], beachte: für Intel-SSDs gelten vermutlich andere Werte).

Damit erstelle ich eine Partition, wobei ich einfach die Vorschläge von fdisk zur Platzierung von Anfang und Ende übernehme. Ergebnis:

~# fdisk -l /dev/sda

Disk /dev/sda: 120.0 GB, 120034123776 bytes
 30 heads, 16 sectors/track, 488420 cylinders, total 234441648 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x371cd7e3

Device Boot      Start         End      Blocks   Id  System
 /dev/sda1            2048   234441647   117219800   83  Linux

Bemerkung: Zur Sicherheit kann man mit „parted“ auch nochmal prüfen, ob die Partition wirklich „aligned“ ist (Tipp aus [2]):

 ~# parted /dev/sda align-check opt 1
1 aligned

Schritt 2: Erstellen des Dateisystems

Ich erstelle ein EXT4-Dateisystem ohne Journal.

Begründung: Bei meinem Layout liegen auf SSD prinzipiell die folgenden Verzeichnisse:

/bin
/boot
/etc
/lib
/opt
/root
/sbin
/usr

das heisst, die permanent systemweit installierten Anwendungen, ihre Bibliotheken und Konfigurationsdateien sowie das Boot-System bestehend aus Bootloader-Konfiguration, Kernel und initrd. Da dort sowieso nur sporadisch geschrieben wird (bei Updates und De-/Installationen), ist die Gefahr des Verlusts der aktuellsten Daten und Dateien deutlich niedriger als z.B. bei meinem Home-Verzeichnis. Ausserdem ist alles wiederherstellbar.

Ich belasse die Block-Size auf dem Default und setze stride und stripe-width wie von [1] empfohlen. Also:

mkfs.ext4 -O^has_journal -E stride=32,stripe-width=32 /dev/sda1

Hinweis: Der von mkfs.ext4 gewählt Wert für Block-Size war 1024, d.h. 1kB. Eine größere Block-Size hat vermutlich eine bessere Performance.

Schritt 3: Kopieren der Dateien

Ich binde das zukünftige /-Dateisystem an einem Mountpoint ein:

mkdir /mnt/ssd
mount -o noatime,nodiratime,discard /dev/sda1 /mnt/ssd

Ich kopiere alle Daten aus / ausser denen, die auf anderen Medien liegen bzw. liegen sollen:

rsync -avzp \
   --exclude /cdrom \
   --exclude /dev \
   --exclude /home \
   --exclude /lost+found \
   --exclude /media \
   --exclude /mnt \
   --exclude /proc \
   --exclude /run \
   --exclude /sys \
   --exclude /tmp \
   --exclude /var \
   / /mnt/ssd

Ich erstelle die Einhängepunkte für separate Dateisysteme neu:

mkdir /mnt/ssd/{cdrom,dev,home,media,mnt,proc,run,sys,tmp}

Ich lege einen Einhängepunkt für das bisherige /-Dateisystem an, diesen werde ich später für die bind-Mounts von /var und /home benutzen:

mkdir mnt/hd

Schritt 4: Vorbereiten des neuen /-Dateisystems

Für die weiteren Arbeiten emuliere ich das neue /-Dateisystem, in dem ich die virtuellen Dateisysteme bereitstelle:

cd /mnt/ssd
mount --bind /dev dev
mount --bind /dev/pts dev/pts
mount --bind /home home
mount -t proc proc proc
mount --bind /run run
mount --bind /tmp/ tmp
mount --bind /var var

Schritt 5: Anpassen der fstab

Ich stelle die UUIDs der Partitionen fest.

~# blkid /dev/sdb2 /dev/sda1
 /dev/sdb2: UUID="86fb5457-f1b3-4649-b78e-324dbb6331b9" TYPE="ext3"
 /dev/sda1: UUID="5949877c-7c3b-420c-8aa6-c8a4a8154ad8" TYPE="ext4"

Nun wechsle ich in die neue /-Umgebung:

chroot .

Das Prompt wechselt zu etwas wie „meinrechner:/# “ und zeigt damit an, dass ich mich jetzt im / des neuen Dateisystems auf sda1 befinde.

Ich ich editiere die [CHROOT]/etc/fstab und ersetze die Zeile

UUID=86fb5457-f1b3-4649-b78e-324dbb6331b9 / ext3 errors=remount-ro 0 1

durch

UUID=5949877c-7c3b-420c-8aa6-c8a4a8154ad8 / ext4 noatime,nodiratime,discard,errors=remount-ro 0 1

Desweiteren möchte ich die bisherigen Daten in /home und /var auf sdb natürlich weiter verwenden.  Also mounte ich auch sdb und hänge dann mit bind-mount die dortigen Unterverzeichnisse des alten / in das neue / ein:

UUID=86fb5457-f1b3-4649-b78e-324dbb6331b9 /mnt/hd ext3 errors=remount-ro 0 1

/mnt/hd/home /home none bind 0 0
/mnt/hd/var /var none bind 0 0

Schritt 6: Auswahl des IO-Schedulers „noop“

In der chroot installiere ich das Paket „sysfsutils“

[CHROOT]~# aptitude install sysfsutils

In die Datei [CHROOT]/etc/sysfs.conf füge ich folgende Zeile ein:

block/sda/queue/scheduler = noop

Damit wird I/O scheduler für die SSD „noop“, für die HD bleibt es beim Default „cfq“.

Schritt 7: Anpassen und Installieren des Bootloaders grub2

Ich editiere [CHROOT]/boot/grub/device.map und füge sda als neuen Eintrag in der zweiten Zeile hinzu (Hinweis: das By-Id-Device von sda habe ich natürlich einfach durch Auflisten von /dev/disk/by-id ermittelt):

(hd0)   /dev/disk/by-id/ata-WDC_WD5000AAKS-00D2B0_WD-WCASY5150535
(hd1)   /dev/disk/by-id/ata-OCZ-VERTEX2_OCZ-X748221DR00JEV1U

Danach führe ich (in der chroot!) folgende Befehle aus:

update-grub
grub-install /dev/sda

Ich öffne zur Prüfung des Ergebnisses die Datei [CHROOT]/boot/grub/grub.cfg und suche dort nach Zeilen wie

...
search --no-floppy --fs-uuid --set=root 5949877c-7c3b-420c-8aa6-c8a4a8154ad8
...

Wenn dort die UUID des SSD verwendet wird statt wie in der alten grub.cfg die der HD, war die Aktualisierung von grub2 erfolgreich.

Schritt 8: Anpassen des BIOS und erster Boot in das neue System

Ich reboote den Rechner.

Ich gehe in das BIOS-Setup und stelle sicher, dass in der Bootreihenfolge das SSD als aller erstes kommt. Dadurch werden lästige Wartezeten auf den grub2-Menübildschirm reduziert.

Wenn alles funktioniert hat, bootet mein neues System, und zwar deutlich schneller als vorher.

Und das tat es. 🙂

Quellen (u.a.):

[1] Markus Ewald, 24,12. 2009: „Aligning an SSD on Linux“ und Diskussion;
URL: http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux

Bemerkung: Ich habe nicht alle Anweisungen aus diesem Dokument befolgt. Ich habe z.B. die Partition auf dem SSD nur vom Anfang her aligned, das Ende ist mir egal, bzw ich habe die maximale Größe gewählt.

[2] ubuntuusers.de › Wiki › SSD › Alignment
URL: http://wiki.ubuntuusers.de/SSD/Alignment