mdadm Softraid on SSD with TRIM

Seit Kernel 3.7 unterstützt das mdadm Softraid den TRIM Befehl.

SSDs benötigen Idealerweise Raum für ihren Wear leveling Algorithmus. Da das mdadm RAID aber die gesamte Partition als „belegt“ beansprucht, hat der SSD Controller wenig Ausweichmöglichkeiten und die Schreibperformance geht in den Keller. Da kann man nur die Spare Area mit hdparm vergrößern – verschenkt aber damit wertvollen Platz. Dateisysteme (z.B. ext4) verstehen schon länger den TRIM Befehl (Mountoption „discard“) – aber dies nützt(e) nichts wenn das Dateisystem auf einem Softraid liegt.

Bis Kernel 3.7 bekam man nur folgendes zu sehen:

root@node:~# fstrim /
fstrim: /: FITRIM ioctl failed: Operation not supported

Ab Kernel 3.7 sieht es dann besser aus:

root@node:~# fstrim -v /
/: 12858519552 bytes were trimmed

dd: Ende der Platte löschen

Um z.B. eine (Soft-)RAID-Signatur von einer Festplatte zu entfernen reicht es meist (je nach RAID Typ) die letzten Bytes der Platte zu löschen, da sich die Signatur meist am Ende einer Partition befindet. So erspart man sich ein langwieriges Löschen der kompletten Platte.

Einen Weg der ohne Rechnerei und viel Script auskommt habe ich so schnell nicht gefunden, daher nutze ich diese Methode:

sudo blockdev --getsz /dev/sda
250069680 # anzahl der Blöcke (512Byte)
 
sudo dd if=/dev/zero of=/dev/sda bs=512 seek=250060000

Nicht sonderlich elegant – ich nulle die letzten Bytes der Blockgrösse damit diese übersprungen werden und lasse dann dd bis zum Ende der Platte laufen. dd bricht dann mit „no space on device“ ab – aber die letzten Bytes wurden dabei sauber geleert 😉

mdadm: Device or resource busy

Beim Hinzufügen einer neuen Partition zu einem RAID kam vorhin folgende Meldung:

mdadm --add /dev/md0 /dev/sda1
mdadm: Cannot open /dev/sda1: Device or resource busy

Gemounted war die Partition nicht – was ich jedoch nicht beachtet hatte war, dass der device-mapper sich die Platte beim booten geschnappt hatte:

dmsetup ls
ddf1_System	(253, 0)
ddf1_Systemp2	(253, 2)
ddf1_Systemp1	(253, 1)

D.h. ich musste die Platte noch aus der device-mapper Verwaltung herausnehmen:

# Entfernt alle (!!!) Platten aus der Verwaltung des device-mapper
dmsetup remove_all

Danach klappt auch das hinzufügen mit mdadm wieder:

mdadm -a /dev/md0 /dev/sda1
mdadm: added /dev/sda1

Jeder erste Sonntag im Monat

Wer sich wundert, warum er am ersten Sonntag im Monat ganz früh morgens aus dem Bett geklingelt wird, hat vermutlich ein Debian oder Ubuntu System und Probleme mit dem Soft-Raid.

Auf diesen Systemen führt cron um 00:57 (wie gesagt nur am ersten Sonntag im Monat) einen Check der Soft-Raid Partitionen durch. Eine wichtige Maßnahme – werden dadurch doch recht früh Fehler am IO-System (Bad Blocks etc.) aufgedeckt (und nicht erst wenn es zu spät ist).

md: data-check of RAID array md0
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
md: using 128k window, over a total of 48829440 blocks.

BTW: Bei RedHat/Centos wird der gleiche Check über cron.weekly (jeden Sonntag 4:22) ausgeführt. Manuall triggert man einen solchen Check über:

echo check > /sys/block/md0/md/sync_action

RAID1 in RAID5 umwandeln

Wenn Speicherplatzbedarf ständig wächst und Datensicherheit wichtig ist, bietet sich ein RAID5 an. Soweit bekannt. Nur was ist zu tun, wenn man zunächst nur auf Datensicherheit (RAID1) gesetzt hat, später aber feststellt, dass man gerne mehr Speicherplatz und Datensicherheit (RAID5) hätte?

Laut Theorie ist ein RAID5 mit 2 Laufwerken nichts anderes als ein RAID1 (Spiegelung). Die Parity-Informationen entsprechen dann einer Spiegelung des Laufwerks. Gut erklärt wird das z.B. hier. Ein RAID1 unterscheidet sich also gegenüber einem RAID5 nur durch einen anderen RAID-Header. Ausprobiert hat das ganze zum Glück auch schon hier jemand. Soweit die Theorie – für die Umsetzung in der Praxis habe ich doch erst mal eine Sicherung der Daten angelegt.

„RAID1 in RAID5 umwandeln“ weiterlesen