SSD Raid Arrays unter Linux IV – Setup von Raid-10-Arrays

Diese Miniserie an Posts befasst sich mit SSD-basierten SW-Raid-Systemen auf Linux-Workstations oder Servern:

SSD Raid Arrays unter Linux – I – Optimiertes SW Raid oder Intel RST Fake Raid?
SSD Raid Arrays unter Linux – II – Optimiertes SW Raid oder Intel RST Fake Raid?
SSD Raid Arrays unter Linux – III – negative Aspekte von Raid-5-Arrays

In letzten Beitrag III dieser Serie hatte ich einige potentielle Nachteile, die Raid-5-Arrays für SSDs mit sich bringen können, angesprochen. In diesem Beitrag gehe ich darauf ein, wie ich meine md-basierten Raid-10-Arrays konkret mit Hilfe des Befehls "mdadm" aufsetze. Dabei gehe ich auf Voraussetzungen und einige wichtige Parameter etwas genauer ein. Eine Verallgemeinerung auf andere Raid-Varianten wie Raid 5 ist danach relativ einfach.

Voraussetzungen und Optimierungen für SSDs unter Linux

Da unsere Raid-Arrays aus SSDs zusammengesetzt werden, sind unter Linux einige Regeln zu beachten. Einen guten Überblick geben etwa folgende Artikel:

https://sites.google.com/site/easylinuxtipsproject/ssd
http://www.linux-magazine.com/Issues/2015/172/Tuning-Your-SSD
https://wiki.archlinux.org/index.php/Solid_State_Drives
https://wiki.debian.org/SSDOptimization

Hier einige Punkte, die mir relevant erscheinen:

  1. Auf allen SSDs, die in das Raid-System eingebunden werden, sollte man grundsätzlich ca. 7-12% frei, d.h. ohne Partition, belassen (Overprovisioning).
  2. Ein periodisches Absetzen des TRIM-Befehls auf Filesystemen per cron-Job ist dem Mounten mit der "discard"-Option vorzuziehen.
  3. Ext4 sollte als Filesystem verwendet werden (in meinem Fall auf LVM Logical Volumes des Raid-Arrays; s.u.)
  4. Man sollte prüfen, dass die eingesetzten Tools zum Einrichten von Partitionen, LVM und Filesystemen das notwendige Alignment korrekt durchführen (YaST etwa tut dies automatisch, wenn unter den Einstellungen "Optimal" als Option gewählt wurde !)
  5. Partitionen sollte man großzügig anlegen - 25% sollten immer als freier Platz zur Verfügung stehen.
  6. Für LVM sind die Optionen
    "md_chunk_alignment = 1" und "issue_discards = 1"
    in der Datei "/etc/lvm/lvm.conf" zu setzen.
  7. Als Scheduler sollten die Low-Latency-Scheduler "deadline" oder "noop" verwendet werden.
  8. Wahl des AHCI-Modus für den SATA-Contoller (soweit nicht Fake Arrays konfiguriert werden).

Punkt 1 dient sowohl der Lebensdauer als auch der Performance von SSDs. Bitte beachtet, dass u.a. dieser Punkt gegen den Einsatz des Intel Fake Raid Controllers (für den Z170 Chipsatz - Sunrise Point SATA Controller) spricht. Grund: Dieser Controller lässt einem keine Wahl bzgl. der Größe des zweiten Raid-Arrays, das man evtl. anlegen will; vielmehr wird dann der gesamte physikalische Platz der Speichermedien genutzt. Siehe hierzu frühere Beiträge der Serie.

Punkt 2 dient der Performance; der TRIM-Befehl [fstrim unter Linux] ist allerdings auch mit Schreib-/Lösch-Operationen verbunden und belastet daher die SSD. Bei hinreichend großen Partitionen genügt im durchschnittlichen Tagesbetrieb nach meiner Erfahrung ein einmaliges Absetzen von "fstrim" pro Woche, um die Performance aufrecht zu erhalten.

Punkt 3 wird in vielen Internet-Artikeln zu diesem Thema als richtig angesehen, da die Node-Behandlung SSD-Controllern entgegenkommt. Die Bevorzugung von ext4 kann sich jedoch ändern, wenn Btrfs einen hinreichenden Reifegrad erhalten hat. Ich ignoriere Btrfs in diesem Artikel, da ich wenig Erfahrung mit diesem Filesystem habe - und die, die ich hatte, waren (noch) nicht gut. Allerdings sind ja auch XFS und zunehmend F2FS sehr populär. Ich behandle diese Filesysteme mangels produktiver Erfahrung nachfolgend nicht. Ein Blick in Tests ist aber sicher interessant (s. etwa:
http://www.phoronix.com/scan.php?page=article&item=linux-40-ssd&num=2,
https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.4-FS-4-Way,
https://www.percona.com/blog/2012/03/15/ext4-vs-xfs-on-ssd/,
http://openbenchmarking.org/result/1608041-LO-LINUX44BT99
https://blog.pgaddict.com/posts/postgresql-performance-on-ext4-and-xfs, https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-FS-5-Way,
http://infoteh.etf.unssa.rs.ba/zbornik/2016/radovi/RSS-2/RSS-2-8.pdf).
Ich sollte dazu sagen, dass ich SSD-Benchmarks ab Kernel 4.4 nicht wirklich traue. Siehe zu Kernelabhängigkeiten einen eigenen Abschnitt weiter unten.
S. aber auch:
https://bbs.archlinux.org/viewtopic.php?id=207938
Die Unterschiede zwischen ext4 und XFS scheinen insgesamt nicht weltbewegend zu sein. Ich ziehe ext4 z.Z. wegen seiner guten Stabilität und wegen seiner guten Wiederherstellungsfähigkeit bei Filesystem-Fehlern im besonderen Btrfs vor. Hinzu kommt, dass ext4 die geringste Schreibbelastung durch Journaling auf die SSDs auszuüben scheint (s. z.B. http://www.ocsmag.com/2016/04/30/using-solid-state-drives-on-linux/). Ferner unterstützt ext4 den fstrim-Befehl garantiert.

Punkt 4 behandle ich im nachfolgenden Abschnitt genauer.

Punkt 5 dient ebenfalls der Performance: Freie Blöcke des Filesystems stehen hinreichend und zusammenhängend zur Verfügung; eine Defragmentierung wird durch Linux-Filesysteme bei hinreichend freiem Platz weitgehend vermieden.

Punkt 6 dreht sich einerseits darum, dass ein Physical Volume, das direkt auf einem md-Raid-Array aufsetzt, automatisch an die zugrunde liegende Raid-Array-Struktur (im besonderen die sog. Chunk Size; s.u.) angepasst wird. Durch den 2-ten Parameter informiert LVM den SSD-Controller ferner über die Freigabe von Platz bei Löschungen oder Verkleinerungen von logischen Volumes. Siehe hierzu:
https://linux.die.net/man/5/lvm.conf,
https://nixaid.com/trim-in-linux-with-ssd-disk-lvm-and-encryption/

Punkt 7 hat damit zu tun, dass bestimmte Linux I/O Scheduler, wie der cfq-Scheduler, versuchen, seek-Zeiten für HDDs zu minimieren. Das ist bei SSDs aber überflüssig und verschwendet CPU-Zeit; Scheduler wie "noop" oder "deadline" verringern dann die Latenz. Siehe hierzu und zur Einrichtung des Schedulers für SSDs die folgenden Links:
http://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler
https://wiki.debian.org/SSDOptimization

Punkt 8 ist eine Standard-Empfehlung, die vor allem im Gegensatz zu potentiell möglichen "IDE"-Einstellungen zu sehen ist. Siehe etwa:
http://www.phoronix.com/scan.php?page=article&item=intel_linux_ahci&num=1
http://archive.benchmarkreviews.com/?option=com_content&task=view&id=505
Auf Systemen mit einem Intel-Fake-Raid-Controller gibt es im BIOS oft auch die Option "RAID". Ich habe bei Einrichtung eines reinen md-basierten Linux-SW-Raids auf solchen Systemen keine Performance-Differenzen zwischen den Einstellungen AHCI und RAID feststellen können. Der RAID-Modus fällt wohl auf den AHCI-Modus zurück, wenn der Fake-Controller nicht genutzt wird.

Alignment und die Hierarchie der Speicherorganisation

Punkt 4 ist technisch interessant: Hier geht es um die Ausrichtung von Partitions-Grenzen gemäß der definierten Sektorgrößen der HDDs/SSDs (typischerweise 512 Byte) und ein Ausrichten der Blocksize des Filesystems (für ext4 typischerweise 4KB (genauer 4 KiB (4096 Bytes); 1 MiB = 2048 * 512 Bytes) an der zugrunde liegenden Speicherstruktur.

Eine Erläuterung des Themas findet sich hier:
https://www.thomas-krenn.com/de/wiki/Partition_Alignment
Siehe auch:
https://wiki.ubuntuusers.de/SSD/Alignment/
https://wiki.debian.org/SSDOptimization

Alignment betrifft aber nicht nur Partitionsgrenzen. Alignment ist auf allen Ebenen der HD-/SSD-Speicherorganisation interessant (physikalische Partition, Raid-Array, LVM-Group, LVM-Volume, ext4-Filesystem). Dabei müssen auch Parameter des ext4-Filesystems an die Raid-Speicher-Organisation angepasst werden. In unserem Fall sieht die geplante Hierarchie der Speicherorganisation wie folgt aus:

=> 4 SSDs
=> pro SSD eine unformatierte Raid-Partition (Typ 0xFD)
=> md-Raid-Array mit Striping (je nach Raid-Typ)
=> Eine LVM Volume Group [VG] über das gesamte Raid-Array hinweg; das Raid-Array entspricht dabei einem LVM Physical Volume [PV]
=> Logische LVM Volumes [LVs] mit ext4 Filesystem

Die Anzahl zu lesender und zu schreibender Blöcke für den Erhalt bzw. die Speicherung von Information soll über die gesamte Hierarchie hinweg durch passendes Alignment minimiert werden.

In der Linux-Praxis muss man sich allerdings um ein korrektes Partition-Alignment kaum kümmern. Generell führen "gdisk" und "parted" mit der "-a optimal" Option das notwendige Partition-Alignment korrekt durch. Für Opensuse's YaST-Partitioner kann man unter dem Punkt "Einstellungen" ein optimales Ausrichten von Partitionen anfordern; das führt intern zum Setzen der Option "-a optimal" für "parted". [Ich gehe hier implizit davon aus, dass mit einem GPT-Layout der SSDs gearbeitet wird.]

LVM2 (unter YaST) arbeitet ebenfalls korrekt - und allokiert typischerweise 4MiB große "Physical Extends" [PEs]. (Siehe zu LVM2-Grundlagen etwa https://www.thomas-krenn.com/de/wiki/LVM_Grundlagen). Das passt zu allen vorherigen Einstellungen. Typischerweise wird man eine logische Volume-Gruppe [VG] über das gesamte Array anlegen. Durch die oben bereits diskutierten Parameter in der "/etc/lvm/lvm.conf" nimmt das LVM-PV-Layout auch auf die darunter liegende Raid-Array-Speicherorganisation Rücksicht.

Ein potentiell mögliches LVM-Striping von Logical Volumes über die Physikalischen Volumes (PVs) einer Gruppe hinweg fällt in unserem Fall flach. Das Striping wird ja bereits vom md-Raid-Array übernommen.

[LVM-Seitenaspekte: Würden wir aber - was prinzipiell möglich ist - statt md-Arrays LVM-basierte Raid-Arrays einrichten, müssten wir über die sog. LVM-Stripe-Size genauer nachdenken. Die LVM Stripe-Size gibt vor, ab welcher Größe der zu schreibenden Informationsblöcke auf ein neues PV der Logical Volume Group [VG] geschrieben wird. Die Überlegungen, die wir weiter unten zur Chunk Size der md-Raid-Arrays anstellen, sind dazu ganz analog. Interessant wäre übrigens auch ein LVM-Striping über mehrere md-Raid-Arrays (als PVs der VG) hinweg. Auch dann ist die LVM-Stripe-Size von größerem Interesse. Mangels Masse an SSDs habe ich damit aber noch nicht experimentieren können.]

Bleibt noch das Anpassen bestimmter Parameter (stride, stripe-width) des ext4-Filesystems an die darunter liegende Raid-Struktur. (LVM als Zwischenschicht ist diesbzgl. so gut wie transparent!). Erläutert ist dies z.B. hier
https://gryzli.info/2015/02/26/calculating-filesystem-stride_size-and-stripe_width-for-best-performance-under-raid/

Die Filesystem-Parameter (stride, stripe-width) sorgen für eine optimale Gruppierung von Datenblöcken für den Transfer zum bzw. vom Raid-Array. Dabei spielt die sog. Chunk-Size [CS] des Raid-Arrays eine Rolle; diese wird manchmal analog wie bei LVM LVs auch "Stripe-Size" des Raid-Arrays genannt. Ich komme darauf weiter unten genauer zurück. Im Moment mag genügen, dass z.B. der YaST-Partitioner die genannten Parameter korrekt einstellt, wenn ihm die zugrunde liegenden Raid-Array-Parameter bekannt sind.

Dennoch empfehle ich in jedem Fall manuell zu prüfen, ob die Parameter OK sind. Informationen zu den gewählten Parametern eines konkreten ext4-FS erhält man über tune2fs -l, z.B.:

mytux:~ # tune2fs -l /dev/volssd1/lvssdtest
....
RAID stride:              8
RAID stripe width:        16   

 
Wie man die korrekten optimalen Werte anhand des Raid-Typs (hier Raid 10) und der Raid-Chunk-Size bestimmt, erläutere ich in einem Abschnitt weiter unten.

Die Parameter stride und stripe-width können auch im Nachhinein mit Hilfe von tune2fs angepasst werden (s. http://serverfault.com/questions/663066/is-it-possible-to-update-stripe-width-on-an-existing-and-used-ext4-fs).

Weitere Links zum Alignment von SSD-Raid-Systemen finden sich hier:
http://dennisfleurbaaij.blogspot.de/2013/01/setting-up-linux-mdadm-raid-array-with.html
http://serverfault.com/questions/592149/ssd-software-raid-alignment-necessary
https://www.percona.com/blog/2011/06/09/aligning-io-on-a-hard-disk-raid-the-theory/
https://raid.wiki.kernel.org/index.php/RAID_setup

Welche Kernelversion?

Vor einem Monat hätte ich diesen Absatz noch nicht geschrieben. Inzwischen habe ich aber Tests von Raid-Arrays auf verschiedenen Systemen mit Opensuse Leap 42.1, 42.2 und Opensuse Tumbleweed, Debian Jessie und verschiedenen Kernelversionen [4.1, 4.4, 4.7, 4.9] durchgeführt. Leider ist die Performance von Raid-Arrays, ja sogar der zugrunde liegenden SSDs dabei keineswegs eine Konstante. Woran das liegt, ist mir z.Z. ein Rätsel.

Im Moment spreche ich mich bei einem Vorhaben mit SSD-Raid-Arrays aufgrund eigener Tests aber klar für die Kernel-Version 4.1 aus.

Das ist aus meiner Sicht diejenige Kernelversion, die in Tests (z.B. mit FIO) konsistent die höchsten Durchsatzraten mit geringster Variationsbreite bietet. Spätere Kernelversionen haben entweder Fehler bzgl. md-Raid-10-Arrays (4.2, 4.3; s. https://wiki.archlinux.org/index.php/RAID) oder liefern seltsam schwankende Performancedaten (s. https://bugzilla.kernel.org/show_bug.cgi?id=191881).

Schritt 1 zum SW-Raid10-Array: Anlegen von Raid-Partitionen auf den SSDs

In meinem Fall sind die 4 SSDs unter /dev/sda, /dev/sdb, /dev/sdc, /dev/sdd ansprechbar. Auf diesen Platten lege ich auf einem System mit UEFI-BIOS zunächst je eine erste efi-Partition (Fat16) an. Dies ist nur eine Vorsichtsmaßnahme für den Fall, dass ich später doch mal eine bootbare Partition in einem der SW-Raid-Arrays selbst anlegen will (s. hierzu die früheren Artikel dieser Serie).

Danach habe ich auf den SSDs dann im nachfolgenden Beispiel mit Hilfe von "mkfs" je eine weitere unformatierte Partition "/dev/sda[bcd]2" des Typs "0xFD Linux Raid" angelegt. "parted" liefert danach folgende Infos für z.B. "/dev/sdb"; dabei kann die 3-te zusätzlich vorhandene Test-Partion ignoriert werden. Im Moment ist nur die zweite Partition relevant.

(parted) print /dev/sdb
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system  Name     Flags
 1      1049kB  189MB  188MB   fat16        primary  boot
 2      189MB   226GB  225GB                primary  raid
 3      226GB   253GB  26.8GB               primary  raid

 
Warum habe ich die Partition 2 unformatiert gelassen? Weil ich später eine flexible Partitionierung des Raid-Arrays über LVM erreichen will!

Alignment Checks:
Die logische und physikalische Sektorgröße der Samsung EVO 850 ist 512 Byte. Passen dazu die Partitionsgrenzen? Das bekommt man z.B. mit Hilfe von parted heraus.

(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal? optimal                       
Partition number? 2                                                       
2 aligned
(parted)   

 
Wie sieht der Output von fdisk aus?

fdisk -l -u /dev/sdb
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 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
Disklabel type: gpt
Disk identifier: 3BFE79AE-FA81-474E-BB76-082C630414ED

Device         Start       End   Sectors  Size Type
/dev/sdb1       2048    368639    366592  179M EFI System
/dev/sdb2     368640 440774655 440406016  210G Linux RAID
/dev/sdb3  440774656 493211647  52436992   25G Linux RAID

 
Und was sagt sfdisk?

sfdisk -d /dev/sdb
label: gpt
label-id: 3BFE79AE-FA81-474E-BB76-082C630414ED
device: /dev/sdb
unit: sectors
first-lba: 34
last-lba: 976773134

/dev/sdb1 : start=        2048, size=      366592, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=2B60DB9C-3DE1-45AC-80FC-A51657CA5E49, name="primary"
/dev/sdb2 : start=      368640, size=   440406016, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=2F85AE30-BE40-4D49-BE4C-F240EDF48289, name="primary"
/dev/sdb3 : start=   440774656, size=    52436992, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=8A67ED48-0BE2-4E83-8803-F7A42D91F3CF, name="primary"

 
Man sieht, dass die erste (efi-) Partition auf 1MiB (2048 sectors) ausgerichtet ist. Auch alle anderen Partitionen liegen offenbar genau auf Sektorgrenzen.

Analog verfährt man für die anderen SSDs. Unter Opensuse kann man zum Einrichten der Partition bequem YaST's Partitioner verwenden. Bei der Verwendung der Kommandozeile nicht vergessen, die für Raid-Arrays bestimmte GPT-Partitionen auf den Typ 0xFD zu setzen! (genauer: 0xFD00; s. hierzu https://raid.wiki.kernel.org/index.php/Partition_Types).

Schritt 2 zum SW-Raid10-Verbund: Festlegen bestimmter Parameter des Kommandos "mdadm" - Chunk Size, bitmap, layout

Nun wird es Zeit, das Raid-Array zu bilden. Unter Opensuse könnte man das z.B. mit Hilfe von YaST's Partitioner machen. Davon rate ich aber explizit ab, weil YaST leider nur Standardparameter setzt und keine abweichende Setzung ermöglicht.

Vielmehr ist der Befehl "mdadm" mit bestimmten Parametern anzuwenden. Es gibt beim Anlegen von Raid-10-Arrays mit mdadm vor allem 3 Parameter, die für die Performance interessant sind:

  • Parameter "chunk", für die Festlegung der sog. "Raid Chunk Size" [CS],
  • Parameter "bitmap"; der legt fest, ob Daten in Transferprozessen besonders markiert werden; er kann die Resynchronisation von Raid-Arrays beschleunigen.
  • Parameter "layout" zur Festlegung des sog. Near-, Far- oder Offset-Layouts eines Raid-10-Arrays

Zur Bedeutung der Chunk Size des Raid-Arrays

Die Chunk-Size legt fest, aber welcher atomaren Größe Information statt auf genau eine auch auf weitere Platten des Raid-Systems geschrieben wird. Ich zitiere von "https://raid.wiki.kernel.org/index.php/RAID_setup":

The chunk-size deserves an explanation. You can never write completely parallel to a set of disks. If you had two disks and wanted to write a byte, you would have to write four bits on each disk. Actually, every second bit would go to disk 0 and the others to disk 1. Hardware just doesn't support that. Instead, we choose some chunk-size, which we define as the smallest "atomic" mass of data that can be written to the devices. A write of 16 kB with a chunk size of 4 kB will cause the first and the third 4 kB chunks to be written to the first disk and the second and fourth chunks to be written to the second disk, in the RAID-0 case with two disks. Thus, for large writes, you may see lower overhead by having fairly large chunks, whereas arrays that are primarily holding small files may benefit more from a smaller chunk size. ....
For optimal performance, you should experiment with the chunk-size, as well as with the block-size of the filesystem you put on the array. For others experiments and performance charts, check out our Performance page...

Die man-Seite zu mdadm offenbart, dass die Chunk-Size in KiB definiert wird. Viele Artikel zu SW-Raid im Internet empfehlen eine Chunk-Size von ≥ 512KiB. 512KiB ist auch die Default-Einstellung von "mdadm" (welche z.B. auch von YaST herangezogen wird).

Aber ist diese Einstellung auch wirklich gut?
Mißtrauisch sollte einen u.a. die Tatsache machen, dass z.B. der Intel Fake Raid Controller des Z170 Chipsatzes als Default eine viel kleinere Chunk Size von nur 32KiB wählt. Interessant, nicht wahr?

Nun erhält man bei einem Raid-10-System (im sog. NN-Layout; s.u.) ohne Pufferung maximal zweifache Schreib- und Lese-Geschwindigkeiten gegenüber dem Zugriff auf nur eine SSD. Diese Geschwindigkeitsvorteile sind offenbar aber durch einen einzelnen Raid-Zugriff nicht erreichbar, wenn die zu schreibenden oder zu lesenden Informationseinheiten kleiner oder gleich der Chunk-Size sind.

Was einem in diesem Zusammenhang zudem spontan einfällt, ist Folgendes:
Es wird vermutlich einen großen Unterschied machen, ob mehrere Jobs des Betriebssystems gleichzeitig Schreib- oder Lese-Operationen verlangen oder ob nur 1 Job sporadisch kleine Informationseinheiten abgreift bzw. schreibt. So wie im letzteren Fall etwa ein (virtualisiertes) Betriebssystem oder ggf. sequentielle Datenbanktransaktionen.

So wird es auf einem Fileserver mit vielen Usern und bei statistischer Verteilung von Filedaten über die 2 effektiven Platten des Raid-Systems eine große Chunk-Size eher von Vorteil sein - auch wenn pro Job deutlich kleinere Dateibrocken vorliegen. Im Schnitt über alle Jobs liest man dann immer noch von oder schreibt auf 2 Platten gleichzeitig. Bei einer Linux-Workstation, auf der ggf. ein virtualisierter KVM-Gast ausgeführt wird, kann das aber ganz anders aussehen. Zudem besitzen aktuelle SSDs auch noch einen internen Write Cache, der einem dazwischenfunken kann.

Man muss also die konkrete Festlegung der Chunk Size auf sein Zielszenario und die dort gegebenen Verhältnisse anpassen. Bislang habe ich euch noch keine quantitativen Informationen über den Einfluss der Chunk Size geliefert. Im nächsten Beitrag dieser Serie werde ich aber Messdaten und Anhaltspunkte dafür liefern, dass eine CS von 32KiB gar kein so schlechter Kompromiss ist - zumindest für die Kernelversion 4.1.

Man kann die Chunk Size übrigens für ein SW Raid Array im Nachhinein ändern. Das kostet aber erhebliche (!) Zeit, da das Raid-System umgeschrieben werden muss und es während dieser Zeit auch potentielle Ausfälle verkraften muss. Dafür müssen aufwändige Sicherheitsvorkehrungen getroffen werden. Siehe hierzu etwa:
https://forum.ubuntuusers.de/topic/chunksize-bei-mdadm-raid5-onthefly-aendern/
http://serverfault.com/questions/186518/is-it-possible-to-change-the-raid5-chunk-size-of-an-existing-device

Performance-relevant ist natürlich auch, dass die Chunk Size ein ganzzahliges Vielfaches der Blockgröße des Filesystems sein sollte. Im Beispiel dieses Artikels wähle ich

--chunk=32

Zur Bedeutung des "bitmap"-Parameters

Im letzten Artikel hatte ich ein Szenario beschrieben, in dem eine Platte eines Raid5-Systems ausfiel, weil ein SATA-Kabel locker saß. Für solche Fälle können sog. "Bitmaps" helfen, die Rebuild Zeit drastisch zu verkürzen. Hierbei werden bestimmte Raid Chunks, die sich im "Transaktionsstatus" befinden, zunächst als "unclean" markiert. Nach Abschluss der Schreibaktion dagegen als "clean". Durch Zeitstempelvergleiche müssen bei einem temporären Ausfall einer Platte dann nicht alle Blöcke des File-Arrays rekonstruiert werden, sondern nur die als "unclean" markierten.

Zitat aus https://raid.wiki.kernel.org/index.php/Write-intent_bitmap:

When an array has a write-intent bitmap, a spindle (a device, often a hard drive) can be removed and re-added, then only blocks changes since the removal (as recorded in the bitmap) will be resynced. Therefore a write-intent bitmap reduces rebuild/recovery (md sync) time if:
     * the machine crashes (unclean shutdown)
     * one spindle is disconnected, then reconnected.
If one spindle fails and has to be replaced, a bitmap makes no difference.

Aber: die entsprechenden Bitmap-Informationen müssen bei jeder Plattentransaktion auch geschrieben werden. Das kostet Performance; siehe http://blog.liw.fi/posts/write-intent-bitmaps/. Durch Verlagern der Bitmap auf außerhalb des Raid-Systems liegende gepufferte Datenträger kann man die Write-Performance erhöhen. Interne Bitmaps sind aber wirklich performance-einschränkend.

Nun legt z.B. die Raid-Verwaltung von YaST's Partitioner unter Opensuse leider automatisch eine interne Bitmap an, ohne dass man dies unter YaST beeinflussen könnte. Daher sollte man den "bitmap"-Parameter lieber direkt mit dem mdadm-Befehl unter Kontrolle bekommen.

Da die Rekonstruktion von Raid10-SSD-Arrays im (NN-Layout) recht schnell von statten geht, verzichtet man für eine optimale Write-Performance von Raid-10-Arrays über SSDs eher ganz auf das Anlegen einer Bitmap. Meine Wahl für die zugehörige Option des mdadm-Befehls ist also (s. zur Syntax die man-Seite zu mdadm):

--bitmap=none

Erwähnt sei hier, dass das Anlegen von Raid-Arrays mit Hilfe von BIOS-Funktionen für den Z170-Fake-Raid-Controller (genauer des Sunrise Point-H Sata Controllers) von Intel nicht zum automatischen Anlegen einer Bitmap führt. Bei Performancevergleichen zwischen reinen SW-Raids und Fake-Raids ist das zu berücksichtigen. Dabei gilt nach eigenen Tests:

Ein mit Hilfe vom mdadm angelegtes reines SW-Raid ist ohne Bitmap mindestens so schnell wie ein mit BIOS-Funktionen angelegtes Raid-Array eines Intel-Fake-Raid-Controllers.

Zur Bedeutung des Layouts für md-basierte SW-Raid-10-Arrays

Man kann sich Raid 10 z.B. als eine Kombination aus Raid 1 und Raid 0 vorstellen (Stripe of Mirrors). Aber das "raid10"- und das "md_mod"-Modul für "komplexe" SW-Raid10-Arrays unter Linux erlauben über eine spezifische, direkte Raid-10-Umsetzung interessante zusätzliche Dinge. U.a. kann man Daten über verschiedene Bereiche der beteiligten Platten so verteilen, dass im optimalen Fall immer mehr als 2 effektive Platten die Leseperformance beeinflussen. Man spricht dann von sog. "Raid10-Layouts":

  • das sog. Near Layout entspricht im wesentlichen einem Raid1+0-Layout.
  • Dass Far-Layout und Offset-Layout verteilen die Daten dagegen versetzt über die die Laufwerke; man nähert sich dadurch bzgl. des Lesens einem Striping über 4 Disks an. Das erhöht die Leseperformance drastisch in Richtung eines Raid-5-Systems - es kann aber zu Lasten der Schreib-Performance aufgrund zusätzliche Seek-Zeiten gehen.

Bzgl. der präzisen Organisation über verschiedenen Platten bzw. Plattenbereiche hinweg unterscheiden sich die Layouts deutlich. Das beeinflusst nicht nur die Performance: So ist dass Offset-Layout weniger gegen Ausfälle gewappnet als das Near- oder Far-Layout.

Wer mehr über md-Raid-10-Layouts erfahren möchte, kann etwa folgende Artikel zu Rate ziehen, die die Datenveteilung über die beteiligten Devices z.T. mit schönen Grafiken erklären:

http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-raid-10-layouts-performance-near-far-and-offset-benchmark-analysis.html?start=1
https://www.suse.com/documentation/sles10/stor_admin/data/raidmdadmr10cpx.html
http://serverfault.com/questions/139022/explain-mds-raid10-f2
http://xmodulo.com/setup-raid10-linux.html
http://blog.jamponi.net/2007/12/some-raid10-performance-numbers.html

Der Leser muss sich für ein bestimmtes Layout entscheiden - und sollte die Performanceunterschiede idealerweise vorher mit Hilfe von Test-Arrays ermitteln. Mir persönlich kommt es auf gute Schreibperformance auch im Random-Bereich an. Ich verhalte mich daher konservativ und nutze das N2-Layout (also ein Near-Layout):

--layout=n2

Das ist übrigens auch der Defaultwert von mdadm.

Schritt 3 zum SW-Raid10-Array: Zusammenbinden der Raw-Partitionen der SSDs mittels "mdadm"

Wir sind nun soweit, den mdadm-Befehl abzusetzen. Danach wird Linux sofort beginnen, das Raid-Array aufzubauen; dies entspricht einem erstmaligen Synchronisationsprozess.

mdadm --create --verbose /dev/md127 --level=raid10 --bitmap=none --chunk=32 --layout=n2 --raid-devices=4 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2

 
Das Raid Device sollte hier mit "/dev/mdijk" bezeichnet werden. "ijk" steht dafür für drei Ziffern. Ein Device mit denselben Ziffern sollte es natürlich noch nicht geben (Check etwa mit cat /proc/mdstat). Daneben kann man dem Device aber auch noch einen echten "Namen" geben (s.u.).

Ist das Raid Array fertig sychronisiert, so zeigt einem etwa ein Blick in "/proc/mdstat":

mytux:~ # cat /proc/mdstat
Personalities : [raid10] [raid6] [raid5] [raid4] 
md127 : active raid10 sdc2[2] sdb2[1] sdd2[3] sda2[0]
      440143872 blocks super 1.2 32K chunks 2 near-copies [4/4] [UUUU

 

Optionaler Schritt 3.1 zum SW-Raid10-Verbund: Beschleunigung des (Re-) Synchronisations-Prozesses

Synchronisation der Disks oder Partitionen, aus denen ein Array besteht, erfordert Zeit und belastet natürlich CPU wie I/O-Subsysteme. Wie für echte HW-Raid-Controller gibt es daher auf für SW-Raids Parameter, die es erlauben, die Performance der entsprechenden Hintergrundsprozesse zu steuern. Defaultwerte sorgen für eine geringe Gesamtbelastung des laufenden Betriebssystems.

Ich setze auf meinem System daher regelmäßig zwei relevante Parameter (speed_limit_max, speed_limit_min) nach oben - dies führt zu einer substanziellen Beschleunigung des Sync-Vorgangs, der für Raid10-SSD-Arrays mit effektiven 400GB auf modernen Systemen deutlich unter 5 Minuten abgeschlossen werden kann. Bei Default-Einstellungen würde das viel länger dauern.

echo 500000 > /proc/sys/dev/raid/speed_limit_max
echo 200000 > /proc/sys/dev/raid/speed_limit_min

Das kann man auch während des laufenden Sync-Prozesses absetzen. Wie sich das auf die Sync-Performance auswirkt, kann man etwa an folgendem Output für ein anderes Array auf einem anderen System ablesen:

alpha:~ # echo 500000 > /proc/sys/dev/raid/speed_limit_max
alpha:~ # echo 200000 > /proc/sys/dev/raid/speed_limit_min
alpha:~ # cat /proc/mdstat
Personalities : [raid10] 
md_d0 : active raid10 sdd3[3] sdc3[2] sdb3[1] sda3[0]
      167651328 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      [===>.................]  resync = 16.3% (27408896/167651328) finish=6.0min speed=384214K/sec
      
unused devices: <none>
alpha:~ # cat /proc/mdstat
Personalities : [raid10] 
md_d0 : active raid10 sdd3[3] sdc3[2] sdb3[1] sda3[0]
      167651328 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      [===>.................]  resync = 18.8% (31654272/167651328) finish=4.6min speed=486124K/sec
      
unused devices: <none>
alpha:~ # cat /proc/mdstat
Personalities : [raid10] 
md_d0 : active raid10 sdd3[3] sdc3[2] sdb3[1] sda3[0]
      167651328 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      [===>.................]  resync = 19.3% (32462592/167651328) finish=4.2min speed=525478K/sec

 
Man beachte das schnelle Ansteigen des "speed"-Wertes nach Anheben der Werte von "speed_limit_max" und "speed_limit_min".

Optionaler Schritt 3.2: Explizite Benennung des Raid Arrays mittels der "mdadm"-Option "--name"

Eine explizite Benennung setzt die Verwendung der Option "--name" voraus. Siehe hierzu die man-Seiten zu mdadm. Der dafür angegebene String schlägt sich in einem Devicenamen unter /dev/md/name nieder.

Beispiel - wir benennen nachfolgend das Device mit "d00":

mdadm --create /dev/md127 --name=d00 --level=raid10 --bitmap=none --chunk=32 --layout=n2 --raid-devices=4 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2

 

Das Array "/dev/md127" erscheint dann wie folgt

mytux:~ # cat /proc/mdstat
md127 : active raid10 sdb2[1] sdd2[3] sda2[0] sdc2[2]
      440143872 blocks super 1.2 32K chunks 2 near-copies [4/4] [UUUU]

mytux:~ # mdadm --detail /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Fri Dec  2 12:07:25 2016
     Raid Level : raid10
     Array Size : 440143872 (419.75 GiB 450.71 GB)
  Used Dev Size : 220071936 (209.88 GiB 225.35 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Fri Jan 13 14:56:39 2017
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : near=2
     Chunk Size : 32K

           Name : mytux:d00  (local to host mytux)
           UUID : 96fc09a4:f70044d1:4258b0dd:bdfb2b81
         Events : 19

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync set-A   /dev/sda2
       1       8       18        1      active sync set-B   /dev/sdb2
       2       8       34        2      active sync set-A   /dev/sdc2
       3       8       50        3      active sync set-B   /dev/sdd2

 

Tatsächlich findet man folgende Verlinkung

mytux:~ # ls -la /dev/md  
total 0
....
lrwxrwxrwx  1 root root     8 Jan 13 16:10 d00 -> ../md127
....

 

Warum braucht man das?
Ich habe darüber auch eine Weile gerätselt, bis mir aufgefallen ist, dass ein und dasselbe Raid-Array "/dev/md127" bei einem Neustart des Systems auch mal als "/dev/md126" erscheinen kann. Stellt sich die Frage, wer eigentlich beim Booten die Devicenamen festlegt. Antwort: "udev".

Offenbar gibt es hierbei aber Freiheitsgrade. Daher die explizite Namensgebung, um Eindeutigkeit zu schaffen. Nimmt ein User keine explizite Namensvergabe vor, so greifen bestimmte Regeln. Aus "/dev/md129" wird dann etwa der Name "129" (mit dem eindeutigen Device "/dev/md/129").

Da der Name mit anderen Raid-Informationen im Superblock der beteiligten Partitionen hinterlegt wird, kann das Device /dev/md/name immer eindeutig rekonstruiert werden.

Wichtig wird dies etwa bei gezielt vorgenommenen Einträgen in der "/etc/fstab". Da "/dev/md/name" eindeutig ist, kann man in der "7etc/fstab" damit operieren. Z.B., wenn man das Raid Array mit einem Filesystem versehen hat. Allerdings gilt: Best Practice wäre in der "/etc/fstab" die Nutzung der UUID, die dem Raid Array auch zugeteilt wird - wie man oben sieht.

Der YaST-Partitioner zeigt die Raid-Devices übrigens immer unter den vergebenen Namen an.

Dennoch muss ich sagen, dass ich die Logik der Namensvergabe unter mdadm bis heute nicht völlig verstanden habe. Es werden nämlich auch Einträge zu den benannten Raid Arrays in der Datei "/etc/mdadm.conf" vorgenommen (Opensuse; Einstellung des Ortes der Datei über sysconfig. Auf anderen Systemen liegt mdadm.conf möglicherweise unter "/etc/mdadm/mdadm.conf"). Diese Datei wird bei Existenz beim Booten ggf. für das "Assemblen" eines Raid Arrays herangezogen.

Im Besonderen kann es dann zu Problemen kommen, wenn Raid Arrays unter einer bestimmten Betriebssystem-Installation auf der gleichen Hardware-Plattform erzeugt, modifiziert und dann unter einer anderen Betriebssystem-Installation weiterverwendet werden sollen. Manuelle Korrekturen der Datei mdadm.conf nimmt man etwa mit dem sukzessiven Absetzen von befehlen der Art

mdadm -Db /dev/md/name >> /etc/mdadm.conf

für alle Raid-Array Devices vor. Oder alternativ und gleichzeitig für alle Arrays :

mdadm --detail --scan >> /etc/mdadm.conf

Die alten Einträge zu Raid Arrays in der Datei sollte man natürlich löschen. Nach einer manuellen Korrektur von mdadm.conf sollte man unter bestimmten Betriebssystemversionen zur Sicherheit zudem auch noch "mkinitrd" bzw. "update-initramfs -u" laufen lassen - je nachdem wie das "initramfs" angelegt wird.

Der Kernel braucht die Datei "mdadm.conf" allerdings nicht zwingend; er kann die notwendigen Infos auch direkt aus Superblock-Informationen der beteiligten Raid-Partitionen auslesen.

Ich bin bisher ganz gut damit gefahren, den "--name"-Parameter explizit zu verwenden, udev werkeln zu lassen - und bei Inkonsistenzen oder Problemen beim Wechsel zwischen verschiedenen Betriebssystem-Installationen die jeweilige "/etc/mdamd.conf" ganz zu löschen.

Empfehlung
Ich empfehle, als Namen immer explizit eine 3-stellige Nummer anzugeben - z.B. --name=127. "udev" richtet nimmt dann auch die Anlage des Devices als "/dev/md127" vor. Also:

mdadm --create /dev/md127 --name=127 --level=raid10 --bitmap=none --chunk=32 --layout=n2 --raid-devices=4 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2

 
Das funktioniert gut - auch über verschiedene Betriebssysteminstallationen und mdadm-Versionen hinweg.

Umbenennung eines Arrays:
Der Name eines Arrays kann im Nachhinein auch geändert werden. Siehe
http://askubuntu.com/questions/63980/how-do-i-rename-an-mdadm-raid-array
http://www.unixbulletin.com/rename-an-mdadm-raid-array/

Wie geht man dabei vor? Nehmen wir ein Beispiel-Array, dem die Bezeichnung "--name=d00" mitgegeben wurde. Wir wollen das Array künftig unter "/dev/md126" bzw. "/dev/md/126" ansprechen. Folgende Befehlskette ist für die Umbenennung nötig.

mytux:~ # mdadm --stop /dev/md/d00
mytux:~ # mdadm --assemble /dev/md/126 --name=126 --update=name /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mytux:~ # mdadm -Db /dev/md/126 >> /etc/mdadm.conf

 
Danach:

  • Löschen alter Einträge für d00 in /etc/mdadm.conf.
  • Dann Reboot.

Links zum Thema der Raid-Array-Benennung
https://bugzilla.redhat.com/show_bug.cgi?id=606481
https://bugzilla.redhat.com/show_bug.cgi?id=1201962
http://serverfault.com/questions/494569/mdadm-raid-device-name-changed-on-reboot
https://ubuntuforums.org/showthread.php?t=2265120
http://unix.stackexchange.com/questions/23879/using-mdadm-examine-to-write-mdadm-conf
https://wiki.ubuntuusers.de/Software-RAID/
http://unix.stackexchange.com/questions/80501/no-etc-mdadm-conf-in-centos-6
http://askubuntu.com/questions/63980/how-do-i-rename-an-mdadm-raid-array

Schritt 4 zum SW-Raid10-Array: Anlegen einer LVM2 Volume Group und Logical Volumes

Nun könnte man das Array "/dev/mdxxx", wenn man will, direkt formatieren und mit einem ext4-Filesystem versehen. Ich ziehe aus Flexibilitätsgründen aber vor, LVM einzusetzen. Das Anlegen von LVM Volume Groups und LVM Volumes erfolgt nach Lehrbuch. Ich gehe hier aus Platzgründen nicht auf Details ein. Standardparameter können herangezogen werden.

Auf das Setzen der Parameter

"md_chunk_alignment = 1" und "issue_discards = 1"

in der Datei "/etc/lvm/lvm.conf" hatte ich bereits hingewiesen. Siehe hierzu auch :
http://pof.eslack.org/2013/01/12/ssd-alignment-on-linux-with-ext4-and-lvm/
Unter Opensuse kann man erneut YaST's Partitioner zum bequemen Anlegen der Volume Groups und Volumes verwenden.

Schritt 5 zum SW-Raid10-Array: Berechnung und Check der Parameter stride und stripe-width des ext4-Filesystems

Bleibt noch, entweder das Raid-Array direkt zu oder angelegte LVM Logical Volumes mit einem ext4-Filesystem zu versehen. Wir hatten schon erwähnt, dass dabei folgende Größen berücksichtigt werden sollten:

  • Raid-Chunk-Size [CS]: Die Menge an Daten, die auf ein Laufwerk (genauer eine laufwerksbezogene 0xFD-Partition) des Raid-Arrays geschrieben wird, bevor ein Wechsel des Laufwerks erfolgt (s.o.). je nach Striping des Raid-Arrays kann dabei auf mehrere Laufwerke gleichzeitig geschrieben werden.
  • Block-Size [BS] des Filesystems : Das ist die Größe der Dateisystemblöcke in Bytes. Typisch unter Linux: 4096 Byte (4 KiB).
  • Stride-Size [STS] des Filesystems: Entspricht der Chunk Size als Vielfachem der BS. Bei 32 KiB Chunk Size mit 4 KiB Blöcken ergibt sich STS = 32 KiB/ 4 KiB = 8. Für eine Chunk-Size von 512KiB : STS = 128.
  • stripe-width [SW] des Filesystems: Entspricht der Menge an Blöcken, die insgesamt geschrieben wird, wenn volle Chunks parallel auf Laufwerke des Raid-Arrays geschrieben werden. Diese berechnet sich daher als
    STS * Anzahl der effektiv nutzbaren Disk-Partitionen [ENDP].

In eckigen Klammern habe ich dabei Abkürzungen angegeben, die ich nachfolgend in Formeln verwende.

Diese Größen gehen in die notwendige Berechnung der stride- und stripe-width-Parameter des ext4-Filesystems ein. Ist N die Zahl der eingesetzten Raid-Disks (bzw. der zugrunde liegenden Partitionen), so gilt für die Anzahl effektiv nutzbarer Devices ENDP :

ENDP = N/2 für Raid 10 Systeme
ENDP = N-1 für Raid 5 Systeme

Also:

  • Bei einem Raid 10 mit (Partitionen von) 4 SSDs: ENDP = 2.
  • Bei einem RAID 5  mit (Partitionen von) 4 SSDs : ENDP = 3.

Für eine Chunk-Size von 32 KiB ergibt sich auf einem Raid-10-System mit 4 SSDs also:

SW = STS * ENDP = 8 * 2 = 16

Einen Online-Calculator findet man hier: https://busybox.net/~aldot/mkfs_stride.html

Wie man diese Parameter bei Anwendung des mkfs-Befehls einsetzt, entnimmt man der man-Seite zu mkfs.ext4. Siehe hierzu die Option "-E" mit nachfolgenden kommaseparierten Optionen.

Hat man das Filesystem angelegt, kann man die Parameter-werte mit "tune2fs -l" prüfen. Testen sollte man auch, ob man nach einem Mounten /z.B. auf /mnt) den "fstrim"-Befehl erfolgreich ausführen kann (z.B. "fstrim -v /mnt"). Das sollte bei einem Raid10-Array anstandslos funktionieren!

Fazit

Die Anlage eines md-Raid-10-Arrays mit Hilfe des mdadm-Befehls ist eigentlich simpel. Dennoch gibt es selbst bei einer Entscheidung für ein Raid-10-Array eine Vielzahl von Überlegungen, die im Vorfeld anzustellen sind. Ich habe versucht, einige Aspekte zu diskutieren. Letztlich wird es einem aber nicht erspart bleiben, im Vorfeld der Ausstattung eines Produktiv-Systems ein paar Tests zu fahren.

Der "bitmap"-Parameter ist durchaus performance-relevant; insbesondere ist bei Performancevergleichen mit Raids von Fake-Raid-Controllern zu beachten, ob auf dem Fake-Array eine Bitmap genutzt wird oder nicht.

Ein zentraler Parameter in dem ganzen Spiel ist aus meiner Sicht die Chunk-Size. Wir werden im nächsten Beitrag sehen, dass gerade im Random Read/Write-Bereich für Einzeljobs, die kleine Datenmengen schreiben, viel von dieser Größe abhängt.

Ich nehme hier mal vorweg, dass man hier zunächst die Extreme 32KiB und 512KiB für sein Zielszenario austesten sollte. Speziell für Fileserver sind sicher große Chunk-Werte sinnvoll.

Im nächsten Artikel präsentiere ich dann einige Ergebnisse von FIO-Tests für verschiedene Chunk-Size-Parameter unter Kernel 4.1.

Weitere Links

https://wiki.archlinux.org/index.php/RAID
https://wiki.ubuntuusers.de/Software-RAID/
https://wiki.mikejung.biz/Software_RAID
https://infogalactic.com/info/Non-standard_RAID_levels
http://forum.openmediavault.org/index.php/Thread/1333-Tuning-of-ext4-on-LVM-and-RAID/
http://en.linuxreviews.org/Mdadm

SSD Raid Arrays unter Linux – III – negative Aspekte von Raid-5-Arrays

Im letzten Artikel dieser Serie

SSD Raid Arrays unter Linux – II - Optimiertes SW Raid oder Intel RST Fake Raid?

hatte ich am Beispiel des Intel Z170 RST Controllers ausgeführt, dass es auf einem reinen Linux-System für Raid-Setups nicht notwendig ist, einen Intel-Onboard-Fake-Raid-Controller zu bemühen. Man nimmt sich gegenüber einer SW-Raid-Variante Flexibilität; aber auch die erreichbare Performance ist kein Argument gegen einen reinen SW-Raid-Betrieb unter Linux. Bei Einsatz eines SW-Raid-Arrays für SSDs ist unter Linux allerdings ein wenig Umsicht angebracht. U.a. stellt sich die Frage nach der Wahl der Raid-Variante. In meinem Fall für 4 SSDs. Da liegen als grundsätzliche Alternativen etwa Raid-10 oder Raid-5 Arrays nahe.

In diesem Beitrag möchte ich zwei Argumente dafür anführen, dass die Wahl eines Raid-5-Arrays trotz des größeren verfügbaren (und teuren) SSD-Plattenplatz und guter Performance im sequentiellen Bereich nicht unbedingt die beste Entscheidung ist.

Was sprach im HD-Zeitalter gegen Raid-5- oder Raid-6-Arrays?

Zu nennen war hier aus meiner Sicht an erster Stelle der erhebliche Zeitbedarf zur Rekonstruktion eines degraded Raid-5- oder Raid-6-Arrays - z.B. aufgrund einer defekten Platte oder eines ernsten Fehlers im System (ja, letzteres kommt ab und zu auch unter Linux vor). Das galt im Besonderen, wenn man die Zeitanteile für Rekonstruktionsaufgaben im Raid-Controller oder in der Raid-SW zugunsten der produktiven Performance reduziert hatte.

Nun sind SSDs ja sehr viel rascher als konventionelle HDs. Aus diesem Grund sagten einige Sysadministratoren in Internet-Foren sogar eine Renaissance für Raid-5-Arrays im Kontext eines SSD-Einsatzes voraus. Das Argument ist auch in der Praxis nachvollziehbar. Setzt man die Priorität für eine Raid-5-Resynchronisierung auf Mittelwerte, so liegen die Zeiten für ein 1 TB-Array deutlich unter einer Stunde. Das ist aus meiner Sicht OK. Hinzu kommt die bessere Plattenplatznutzung im Vergleich zu einem Raid-10-System.

Das anderes Argument gegen Raid-5 war die meist schlechte Performance für Random I/O-Bereich und dies vor allem bei kleinen Größen der stückweise zu schreibenden Datenmengen. Write-Caches einiger echter HW-Raid-Controller haben hier geholfen; der Einsatz eines Schreibpuffers ist aber mit Risiken verbunden; Batteriepuffer der Controller waren meist obligatorisch. Um das Thema Performance Raid-5 gegenüber Raid-10 im Fall von SW-Raid unter Linux kümmere ich mich genauer in einem der kommenden Artikel. In diesem Artikel beleuchte ich zwei andere Aspekte - nämlich das Resynchronisationsverhalten bei degraded Arrays und dei Ausführung des FSTRIM-Befehls.

Raid 5 mit einem Intel Raid Fake Controller

In meiner grenzenlosen Naivität begann ich bei der Einrichtung meines SSD-Testsystem zunächst damit, mit Hilfe des onboard iRST-Controllers ein Raid 5-System zu etablieren, obwohl ja bekannt ist, dass eine gerade Anzahl von Platten und Raid 5 nicht sonderlich gut zueinander passen. Für Raid 5 sprachen aus meiner Sicht aber folgende Punkte:

  • Bessere Nutzung der (relativ teuren) Plattenkapazität als mit Raid 10.
  • Optimierung vieler (Fake-) Raid-Controller auf Raid 5.
  • Und nicht zuletzt verleiteten mich meine früheren relativ schlechten Erfahrungen mit Raid 10 auf 3ware-Controllern bei Random I/O zu einem Versuch, mal Raid 5 auszuprobieren.

Ich habe deshalb 4 x 500 GB-SSDs [Samsung EVO 850] zu einem Raid 5-Verbund zusammengeschaltet; dabei wurden ca. 460 GB pro Platte effektiv genutzt. Zum Aufsetzen nutzte ich die UEFI-BIOS-Bordmittel für den Intel-Controller (s. den vorhergehenden Post in diesem Blog). Die resultierende Performance war auch überzeugend:

Ein Read-Durchsatz im sequentiellen Bereich um die 1.45 GB/sec und hohe sequentielle Schreibraten im Bereich von 1.1 GB/sec ließen mich zunächst nicht an meinem Vorgehen zweifeln. Hinzu kam - im Vergleich zu Raid 10 - die relativ hohe verfügbare Plattenkapazität (> 1,36 GB bei 4 EVO 850 500GB SSDs).

Das Betriebssystem hatte ich im ersten Anlauf dummerweise auch im Raid-System selbst installiert. Das kostet, wie bereits im letzten Artikel festgestellt, ca. 10% an Performance. Ich habe die voreilige Entscheidung für Raid 5 dann aber aus einem anderen Grund als vordergründigen Performance-Einbußen bereut.

Resynchronisation des Raid-5-Systems nach Ausfall einer Platte

Dann geschah nämlich etwas, dass normalerweise nicht passieren sollte. Ich hatte ein SATA-Verbindungskabel nicht richtig gesteckt. Als das PC-Gehäuse dann mal bewegt wurde, löste sich das Kabel aus der SSD - mit dem Effekt, dass das Array beim nächsten Start in einen "degraded" Zustand überging. Kein Problem, dachte ich. Genau für solche Situationen hat man ja ein RAID-System. Ich ließ das Array danach wieder aufbauen - der Resynchronisierungsvorgang wurde mit der entsprechenden Funktionalität des Fake-Contorllers im BIOS gestartet und die eigentliche Ausführung dann im gestarteten Linux-System vorgenommen. Insgesamt dauerte das nicht so lange wie aufgrund vieler Internet-Artikel zu dieser Thematik und aufgrund eigener Erfahrungen mit Harddisks befürchtet. Ich habe die Zeit nicht gemessen, aber es dauerte, wie gesagt, sicher deutlich weniger als 1 Stunde.

Was mich dann allerdings schockte, war ein Blick auf den SSD-Zustand mit Hilfe des Kommandos smartctl. Ist Smart im Bios aktiviert, so ist eine Zustandsüberprüfung einzelner SSDs (zumindest auf meinem ASRock-Board) sowohl bei Einsatz eines SW-Raids als auch bei Einsatz des Fake-Raid-Controllers möglich.

Die durch den Ausfall betroffene SSD lief bei mir als Device "/dev/sdd". Die übrigen Devices des Raid-5-Arrays unter /dev/sda, /dev/sdb, /devsdc. Unter den vielen ausgewiesenen Smart-Daten stelle ich nachfolgend nur die Anzahl der "Total_LBAs_written" dar:

Total_LBAs_Written
sda : 604127952
sdb : 846533123
sdc : 603302987
sdd: 3763859973 !!

Nach vielen, vielen Testläufen und ca. 10 immer neuen initialen Raid10-Synchronisationen über 100 GB, 200 GB oder 400 GB-Raid-10-Arrays sieht das heute so aus:

Total_LBAs_Written
sda: 979783261
sdb: 1211867704
sdc: 995650995
sdd: 4121599736

Es ist offensichtlich, dass die eine Resync-Aktion für die Wiederherstellung des Raid-5(!)-Arrays über die gesamte Platte "/dev/sdd" hinweg geschrieben hat (Daten- und Paritätsinformationen). Gleichzeitig ging der Parameter "Wear_Leveling_Count" der vom Ausfall betroffenen Platte um 1 Prozentpunkt nach unten. Die Belastung der Platte durch den Raid-5-Resynchronisationsprozess ist also substanziell gewesen.

Die Wiederherstellung eines Raid10-Arrays erwies sich dagegen in Tests relativ harmlos. Dort werden lediglich abweichende, bereits genutzte Blöcke synchronisiert. Die Resynchronisation ist zudem erheblich schneller als bei Raid 5 abgeschlossen.

Wie ist das Schreiben für die Raid-5-Rekonstruktion im Vergleich zu normaler Plattenbelastung zu werten?

Zum Vergleich: Eine in einem anderen System seit 2 Jahren als Betriebssystemplatte mit virtuellen Maschinen im Dauereinsatz, aber nicht in einem Raid-Verbund befindliche Samsung EVO 840 Pro weist heute einen Wert von

Total_LBAs_Written
sdx: 7968906003

auf. Das ist also immer noch weniger als das Doppelte dessen, was mich eine einzige (!) Resync-Aktion einer Raid-5-SSD gekostet hat. Das liegt nun keineswegs am Einsatz des Fake-Raid-Controllers; die Steuerung und Datenverteilung erfolgt auch hier über Funktionen von Linux's SW-Raid-Verwaltungstools mdadm.

Wie oft muss man mit einem solchen Resync-Prozess rechnen? Erst vor kurzem hatte ich mal einen der zugegebenermaßen seltenen Hänger des KDE-Plasma-Desktops auf dem Testsystem. Das System hing danach vollkommen. Ich befürchtete schon das Schlimmste; der Filesystemzustand war zum Absturzzeitpunkt zwar fehlerhaft, der Plattenzustand über das Raid-Array hinweg aber konsistent. Aber dafür gibt es nun leider überhaupt keine Garantie - schon gar nicht im Falle eines Absturzes während eines intensiven Datentransfers (lesend und schreibend) zu einem Raid-5-System. Ein inkonsistenter Zustand der Platten im Raid-System nach einem ernsthaften Systemfehler ist aus meiner Sicht eher wahrscheinlich. Und dann würde zur Sicherheit vermutlich das gesamte Raid-5-System resynchronisiert werden.

Reichweite des TRIM-Befehls

Ein weiterer Punkt, der im Zusammenhang mit SSDs zu beachten ist, ist das Thema der sog. "Write Amplification" (s. https://en.wikipedia.org/wiki/Write_amplification). Flash-Speicher muss vor einem Neubeschreiben erst gelöscht werden; das führt u.U. zu Verschiebungen von Speicherinhalten und mehrfachen Schreiboperationen. Das reduziert potentiell sowohl die Performance als auch die Lebenszeit von SSDs.

Neben den reinen Nutzdaten müssen im Normalbetrieb auf allen Platten eines Raid 5/6-Verbunds Paritätsinformationen geschrieben werden. Write Amplification (durch Verlagerung von Blöcken auf SSDs) trägt also gerade im Fall von Paritäts-Raids zusätzlich zu einer stärkeren Abnutzung der SSDs bei - gerade in kleineren Arrays (< 8 disks). Theoretisch ist aber die Anzahl der insgesamt durchzuführenden Schreiboperationen auch bei Raid 10 ja nicht kleiner als bei Raid 5. Insofern erscheint mir das Thema der Write Amplification als solches allein noch kein Argument für oder gegen Raid 5 oder Raid 10 zu sein. Eine Konsequenz zur Aufrechterhaltung der Performance und zur Vermeidung von Zeitverlust durch Löschungen besetzter Blöcke bzw. Suchen nach freien Blöcken auf der Platte ist aber, dass die Information über freie Knoten mit dahinterliegenden direkt beschreibbaren Speicherelementen regelmäßig upgedated werden muss. Das Filesystem muss den SSD-Controller - gemeint ist hier der Controller auf der SSD und nicht der Fake-Raid-Controller - über freigewordene, ungenutzte Speicherelemente informieren. Der SSD-Controller muss mit den im Rahmen des (S)ATA-Protokolls übertragenen Information natürlich auch was anfangen können; letzteres ist heute weitgehend der Fall. Unter Linux erledigt das der "fstrim"-Befehl für gemountete Partitionen: einerseits erfolgt die Weitergabe der Information zu freien Knoten; andererseits werden dann von den SSD-Controllern sog. "discard"-Operationen für logisch freigegebene Speicherelemente durchführt. Fortschrittliche Controllers sehen zudem regelmäßige Lösch- und Speicher-Reorganisationsverfahren (SSD garbadge collection) auf den SSDs vor. Nun können Betriebssystem und Raid-(Controlling)-SW zwar in intelligenter Weise dazu beizutragen, um "Write Amplification" zu reduzieren. Hierfür sind meist Zwischenpufferungen von Operationen nötig. Siehe hierzu die interessanten Diskussionen unter http://www.webhostingtalk.com/showthread.php?t=1457939
http://cesg.tamu.edu/wp-content/uploads/2012/02/hotstorage13.pdf

Aber:
Das Thema der Speicherfreigabe und -reorganisation bleibt unabhängig von der Anzahl der Schreiboperationen für SSD-Raid-Arrays bestehen. Somit stellt sich für den Einsatz eines bestimmten Raid-Verfahrens für SSDs auch die Frage, ob der "FSTRIM"-Befehl für die verschiedenen Raid-Varianten eigentlich durch die potentiell betroffenen Layer

Linux-Filesystem (z.B. ext4) - Logical Volume einer LVM-Gruppe - Array über Raid-Partitionen - Partitionen verschiedener SSDs

zu den Controllern der beteiligten SSDs durchgereicht wird.

Leider ist das gerade für Raid-5- oder Raid-6-Arrays nicht der Fall - weder im Falle von SW-Raid noch im Falle des Einsatzes eines Intel Z170 Fake-Controllers. Ich erhalte bei entsprechenden Versuchen regelmäßig Meldungen, dass die zugrundeliegende Infrastruktur den fstrim-Befehl nicht unterstützen würde.

Auf meinen Test-Systemen konnte ich dagegen feststellen, dass der FSTRIM-Befehl an logische LVM-Volumes auf Raid-0-, Raid-1- und Raid-10-Arrays anstandslos durchgereicht wird - zumindest für ext4-Filesysteme. (Andere Filesysteme wie BTRFS habe ich nicht getestet; generell herrscht ja die begründete Meinung vor, dass EXT4 dem Verhalten von SSDs am besten entgegenkommt). Das gilt für reines SW-Raid unter mdadm wie auch den Einsatz des Onboard Fake Raid-Controllers von Intel. (Diese Aussagen kann ich genau genommen im Moment nur für Opensuse-Leap 42.1/42.2 (Kernel 4.4) und ein Debian Jessie-Test-Systeme mit Kernel 4.7 treffen.)

D.h. potentielle Einschränkungen der Performance sind zumindest bei ext4-Filesystemen auf Raid-5-Systemen vorprogrammiert, wenn nicht der Plattencontroller selbst die Garbage Collection und Speicherreorganisation übernimmt. Tatsächlich konnte ich für ext4-Partitionen nach Durchführung von Tests, bei denen mehr als 40 % eines Filesystems beschrieben wurden, regelmäßig Performanceverbesserungen nach Absetzen eines FSTRIM-Befehls feststellen. Zwar keine weltbewegenden Änderungen, aber doch im 10% - 20%-Bereich. Einschränkungen der Performance tauchen mit dem Auffüllen einer Partition also mit hoher Wahrscheinlichkeit auf.

Nun wird und wurde von SSD-Herstellern und Kommentatoren im Internet oft angeführt, dass gerade größere SSDs für den professionellen Einsatz selbst für eine regelmäßige Garbage Collection sorgen. Nun habe ich sowohl EVO 840 Pros und EVO 850 Pros mit 500GB Kapazität auf verschiedenen Systemen im Einsatz und setze ab und zu den fstrim-Befehl für eingerichtete Partitionen manuell ab. Die benötigten Zeiten zur Speicherreorganisation dauern für meine Gefühl relativ lange und betreffen manchmal etliche zig GB. Dabei werden offenbar auch echte Operationen auf den Disks durchgeführt. Das spricht aus meiner Sicht zumindest nicht für eine hohe Frequenz der automatischen Garbage Collection der SSD-Controller. Das mag bei anderen SSDs anders sein.

Aus meiner Sicht ist es daher empfehlenswert, vor dem produktiven Einsatz sicherzustellen, dass entweder die eingesetzten SSDs selbst eine Garbage Collection durchführen oder eben der FSTRIM Befehl im angestrebten Raid-Verbund funktioniert.

Warnung von Red Hat vor dem Einsatz von SW-Raid-5 mit SSDs

Eigentlich hätte man ja fast mit dem oben beschriebenen Resynchronisations-Verhalten nach einem Plattenausfall rechnen können: Wenn 1 Platte ausfällt, müssen auf der Ersatzplatte (in meinem Fall die ursprüngliche Platte) ja alle Dateninformationen untersucht, Paritätsinformationen neu berechnet und neu geschrieben werden. Es war naiv anzunehmen, dass man die Platte einfach wieder einhängen könne - und die meisten Informationen beim Resynchronisieren noch als valide erkannt werden würden.

Wie eine Recherche im Internet ergab, warnt Red Hat aus ähnlichen Gründen vor dem Einsatz u.a. von Raid 5 für SSDs; s.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-ssd.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-ssd.html
Zitat:

Red Hat also warns that software RAID levels 1, 4, 5, and 6 are not recommended for use on SSDs. During the initialization stage of these RAID levels, some RAID management utilities (such as mdadm) write to all of the blocks on the storage device to ensure that checksums operate properly. This will cause the performance of the SSD to degrade quickly.

Fazit

Legt man die obigen Erfahrungen zugrunde, so läuft die Entscheidung zwischen Raid 10 und Raid 6 im Normalbetrieb auf

  • eine Abwägung von Performance-Vor- und -Nachteilen,
  • eine Bewertung des effektiv verfügbaren Plattenplatzes
  • und eine Bewertung des SSD-Verschleißes, der im Fall der Resynchronisation eines Degraded Raid-5-Arrays auftritt,

hinaus.

Die Tatsache, dass alle Blöcke eines ausgefallenen Raid-5-Devices bei Resynchronisations-Prozessen neu geschrieben werden, ist für mich jedenfalls Grund genug, auf (SW-) Raid-5 zu verzichten. Das ist schlicht ein Kostenthema. Mag sein, dass neue SSDs länger halten als alte. Aber nach 3 Jahren bereut man es dann plötzlich, dass die Platten ggf. den hohen Belastungen in mehreren Synchronisations-Prozessen ausgesetzt waren. Mich beunruhigt es jedenfalls, wenn eine einzige Resynchronisation der Platte mehr abfordert als 1 bis 2 Jahre Normalbetrieb. Das Kostenargument betrifft aus meiner Sicht vor allem kleinere Unternehmen und Freelancer, die Linux-Arbeitsstationen und -Server einsetzen, deren finanzielle Ressourcen und Möglichkeiten zum Austausch ganzer SSD-Arrays begrenzt sind.

Hinzu kommen potentielle Performance-Einbußen durch ein fehlendes Weiterreichen des FSTRIM-Befehls an Filesysteme auf Raid-5-Arrays. Das relativiert die Performance-Vorteile beim Lesen, die ein Raid-5-System gegenüber einem Raid-10-System aufweist, etwas. Zudem gilt:

Wer aus irgendwelchen Gründen eine verbesserte Lese-Performance unter Raid 10 anstrebt, kann auch mal das Far- der ein Near/Far-Layout des Raid10-Arrays ausprobieren. Das Far-Layout geht allerdings zu Lasten der Schreibperformance - und dies besonderes für Random I/O. Aber Raid-5 ist gerade für häufigen Random I/O kleinerer zu schreibender Datenmengen wenig performant.

Ich komme auf Performance-Aspekte in weiteren Artikeln dieser Serie zurück.

Interessante Links

https://www.thomas-krenn.com/de/wiki/ATA_Trim
https://wiki.debian.org/SSDOptimization
http://cesg.tamu.edu/wp-content/uploads/2012/02/hotstorage13.pdf
https://en.wikipedia.org/wiki/Write_amplification
http://www.webhostingtalk.com/showthread.php?t=1457939
http://serverfault.com/questions/513909/what-are-the-main-points-to-avoid-raid5-with-ssd
https://lowendtalk.com/discussion/10000/don-t-build-ssd-in-raid5
https://www.reddit.com/r/sysadmin/comments/3m9req/how_would_you_configure_an_mdadm_raid_5_w_ssds/?st=ivpbg325&sh=a09d50fd
http://researchweb.watson.ibm.com/haifa/conferences/systor2011/present/session5_talk2_systor2011.pdf
http://superuser.com/questions/461506/intel-matrix-storage-manager-vs-linux-software-raid

Bzgl. der grundsätzlichen Einstellung von LVMs und des Absetzens von TRIM-Anweisungen im Kontext von LVM-Operationen siehe etwa:
http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

Near/Far-Layout füe Linux SW-Raid-10
http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-raid-10-layouts-performance-near-far-and-offset-benchmark-analysis.html?start=1

Bitmaps
http://www.tutorialspoint.com/unix_commands/mdadm.htm

SSD Raid Arrays unter Linux – II – Optimiertes SW Raid oder Intel RST Fake Raid?

Im ersten Beitrag zu SSD-Raid-Arrays unter Linux

SSD Raid Arrays unter Linux – I - Optimiertes SW Raid oder Intel RST Fake Raid?

hatte ich versprochen, die Frage zu beantworten, ob sich der Einsatz des Intel-Z170-SATA3-Controllers als iRST-Controller für reine Linux-Systeme lohnen würde. Einen solchen Controller findet man im Moment auf vielen aktuellen Consumer-Mainboards vor. Ein Beispiel liefert das von mir auf einem Testssystem eingesetzte Board "ASRock Z170 Extreme 7".

Die vorweggenommene Antwort auf die Eingangsfrage ist aus meiner bisherigen Sicht: Nein.

Das gilt, obwohl einfache Tests für RAID 10-Arrays zunächst das Gegenteil anzudeuten schienen.

Grundsätzliche Anmerkungen zum Intel RST Controller

Intels Z170 SATA3 Controller im iRST-Modus entspricht einem Raid-Fake-Controller mit minimaler Intelligenz - aber guter Boot-Unterstützung. Im AHCI-Modus behandelt der SATA3-Controller die angeschlossenen SSDs über das SATA3-Interface als einzelne Platten. Der iRST-Modus lässt sich im BIOS über die Option "Array" statt AHCI aktivieren.

Der iRST-Modus zieht eine Zwischenschicht zum (UEFI-) BIOS ein und benutzt für die Datenorganisation eines Raid-Verbunds ein eigenes Container-Metaformat (sog. "imsm"-Container). Bei hinreichender Plattenanzahl können auch mehrere Raid-Container angelegt werden, die sich über jeweils unterschiedliche, disjunkte Gruppen von vorhandenen Platten erstrecken. Hat man einen Raid10-Verbund als Ziel und nur 4 Platten zur Verfügung, so ist bereits mit einem Container das Ende der Fahnenstange erreicht.

Ein imsm-Raid-Container, der sich über n definierte Platten hinweg erstreckt, kann genau zwei sog. Raid-Volumes (entspricht landläufigen Raid-Arrays) enthalten. Für das erste Volume ist die Kapazität noch festlegbar; das zweite nutzt dann aber den kompletten Rest der verbliebenen Container-Kapazität. Die Kapazitäten sind im Nachhinein nicht veränderbar. Die zwei möglichen Volumes erstrecken sich über dieselbe Anzahl an Platten; die 2 Volumes können aber 2 verschiedenen Raid-Levels (z.B. Raid 1 und Raid 10) zugeordnet werden (Intel Raid Matrix Technologie). Ein Volume - also ein Raid Array - steht unter Linux (mit aktiven Raid-Modulen) dann als ein partitionierbares Block-Device zur Verfügung.

Der/die Raid-Container mit jeweils maximal 2 Raid-Volumes können bereits im (UEFI)-BIOS (über ein OpROM Optionsmenü für Storagesysteme) erstellt werden. Je nach Board, BIOS und OpRom-Einstellungen ist das iRST-Setup-Menü über eine spezielle Tastenkombination (Ctrl-I) während des BIOS Self-Tests oder durch einen Menüpunkt im UEFI-Interface selbst zugänglich. Oft unter "Advanced" - nach dem man vorher unter einem Punkt "Storage" (o.ä.) die Behandlung der SSDs von "AHCI" auf "RAID" umgestellt hat.

Die Möglichkeit zur Anlage von Raid-Containern und Arrays über BIOS-Funktionen ist im Besonderen für Dual-Boot-Systeme mit Windows nützlich.

Auf einem reinen Linux-System kann man Container wie Volumes in einem laufenden System aber auch über das Raid-Administrations-Tool mdadm erstellen und verwalten - unter Angabe des imsm-Metadaten-Formats (mdadm-Option "-e imsm"). Bei Linux-Installern, die während des Install-Prozesses den Rückgriff auf Terminals erlauben, geht das auch während des Installierens.

So weit, so gut. Es ist auf den ersten Blick durchaus bequem, bereits vor einer Linux-Installation die Raid-Arrays über UEFI-BIOS-Funktionen anzulegen, um sie dann schon während der Installation als einfache Pseudo-Laufwerke vorzufinden, die man direkt formatieren kann. Man kann eine solche Partition z.B. als efi-Partition nutzen und auf einer weiteren Standard-Linux-Partition das Betriebssystem installieren. Unter Opensuse Leap 42.1/42.2 klappt das ohne Probleme.

Die Volumes der angelegten Container sind auf einem Dual-Boot-System auch von der Windows-Installation aus ansprechbar, formatier- und bootbar. Das ist ein echter Vorteil des iRST.

Details zu iRST - im Besonderen zur Einrichtung unter Linux mit Hilfe von mdadm - findet man hier:
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/rst-linux-paper.pdf
https://en.wikipedia.org/wiki/Intel_Matrix_RAID
http://www.intel.de/content/www/de/de/support/boards-and-kits/000005789.html
http://www.intel.de/content/www/de/de/support/boards-and-kits/000006040.html
http://www.intel.com/content/dam/support/us/en/documents/solid-state-drives/RSTe_NVMe_for_Linux_SW_User_Guide.pdf
http://www.intel.com/content/dam/support/us/en/documents/
chipsets/rste/sb/intelr_rste_linux.pdf

Fragen

Es stellen sich sofort zwei Fragen:

  • Wer oder was steuert eigentlich bei einem laufenden Betriebssystem [OS] die Datenverteilung auf die Platten? Das OS oder der iRST-Controller?
  • Will man als Linux-Admin das OS überhaupt auf einer Partition eines [iRST-] Raid-Arrays installieren?

Zur ersten Frage: Die Funktionalität der definierten Container und ihrer Arrays hängt ganz von Treibern und den Fähigkeiten des gebooteten Betriebssystems ab. Der iRST wird unter Linux durch angepasste Komponenten/Module des "md"-Raid-Systems und administrationsseitig durch mdadm unterstützt. Ohne die Steuer-SW und zugehörige Module (u.a. md_mod, raid5, raid10, etc.) unter Linux geht gar nichts.

Eigentlich ist der iRST also ein sog. Fake Controller: Die Hauptarbeit wird nicht durch den Controller selbst, sondern durch das Betriebssystem und zugehörige Software (Treiber) geleistet. Es ist deshalb zwar nicht ausgeschlossen, aber zumindest unwahrscheinlich, dass der in mdadm integrierte spezielle iRST-Treiber unter Linux besondere Performancevorteile gegenüber einem reinen, nativen SW-Raid, das man auch mit mdadm aufsetzt, bieten wird.

Zur zweiten Frage: Diese Frage ist eigentlich unabhängig von der Frage des Einsatzes eines iRST oder SW-Raids. Aus meiner Sicht gilt: Nein, man will keineswegs in jedem Fall das OS auf einer Partition des geplanten und möglicherweise einzigen SSD-Raid-Arrays installieren.

Dies gilt vor allem dann, wenn das geplante Raid-Array nicht die Ausfallsicherheit, sondern primär die Performance bestimmter I/O-lastiger Anwendungen verbessern soll.

Installiert man das OS direkt auf einer Partition eines vorgesehenen (Daten-) Raid-Arrays, so hat das spürbaren (!) Einfluss auf die Gesamt-Performance dieses Raid-Systems und dessen Latenz. Random I/O-Prozesse des OS interferieren dann mit denen der Anwendungsprozesse, die man ja eigentlich mit Hilfe des Raid-Systems performanter machen will.

Die Frage, ob das OS auf einem Raid-System liegen soll, hängt deshalb aus meiner Sicht stark von der Anzahl erstellbarer Raid-Arrays (bzw. im Fall des iRST von der Anzahl erstellbarer separater Container) und deren Einsatzzweck ab. Ich sehe für eine Installation des OS auf einem Raid-Array, das primär für performanten Daten-I/O bestimmter Anwendungen gedacht ist, keinen vernünftigen Grund. (Es sei denn, man möchte aus irgendwelchen Eitelkeiten heraus extrem schnelle Bootzeiten produzieren.)

Will man das OS aber aus Gründen der Ausfallsicherheit auf einem SSD-Array anlegen, dann bitte auf einem separaten Array (bzw. beim iRST: auf einem Volume eines separaten Containers), das nicht auch gleichzeitig die Daten geplanter Hochperformance-Anwendungen beherbergt. Wenn es im OS Prozesse gibt, die substanziell vom I/O auf die SSDs abhängen (Beispiel Datenbanken), so sollte man versuchen, deren Datenhaltung ins Daten-Raid-System zu verschieben oder aber im RAM zu puffern.

Im Falle produktiver High-Performance-Systeme ist das OS in der Regel auf einem separaten Raid 1-System mit ggf. teuren Enterprise SSDs viel besser aufgehoben als auf einem auf Performance ausgelegten Plattensystem aus Raid10-Gruppen. Auf Test- und Desktop-Systemen kann man das OS auch auf einer einzelnen normalen Enterprise-tauglichen SSD (mit regelmäßigen Backups) oder gar einer normalen Harddisk liegen, wenn man nicht zwingend superschnelle Bootzeiten haben muss.

Zudem gilt u.U., dass das Raid-System für das OS aus Performancegründen eine andere Parametrierung erfordert als ein Array für Daten von Anwendungen mit einer ganz bestimmten Last-Charakteristik. Ein System, das laufend durch kurze einzelne und sequentielle I/O-Spikes für kurze Datenblöcke (< 16KB) gekennzeichnet ist, benötigt andere Parameter als ein Raid-Array, das laufend viele parallele Anfragen nach unterschiedlichen Dateien mit einer Größe > 1 MB abdecken muss. Und weiter gilt: Man muss ein OS auch booten können, wenn das Raid-System aus irgendeinem Grund mal ausfallen sollte. In meinem Test-System lege ich das Haupt-OS allein schon aus diesem Grund auf eine separate SSD und mache davon regelmäßige Backup-Abbilder per LVM-Snapshot auf ein Standard HDD-Raid10-System auf einem anderen Server. Das OS ist im Zweifel schnell aus einem Backup rekonstruiert. Mit einem "degraded Daten-Array" kann man sich dann kontrolliert von einem funktionierenden separaten OS aus befassen. Die Rekonstruktion eines defekten degraded Raid-Arrays aus einem auf dem Raid selbst liegenden OS heraus ist generell keine gute Idee. Eine von Haus aus schlechte Restaurierungs-Performance von Raid-5-Arrays würde dadurch noch schlechter. Wann immer man mit Raid-Systemen operiert, gilt übrigens:

Keine einzige Raid-Variante entbindet von regelmäßigen Backups!

Das liegt auf der Hand und ist für Zweifler so oft im Internet begründet worden, dass ich hier auf weitere Ausführungen verzichte. Nun aber zurück zum Einsatz eines iRST-Controllers.

Raid 10 aus 4 SSDs - sequentielle I/O-Performance mit dem iRST

Wir betrachten nachfolgend die Performance eines mit Hilfe des Z170-iRST-Controllers erstellten Raid10-Verbands aus 4 850 EVO SSDs von Samsung. Verglichen wird das iRST-Raid-Array mit einem reinen Linux-SW-Raid-Array, das mit denselben Platten aufgesetzt wurde.

Das Betriebssystem lag in beiden Fällen auf einer separaten SSD und nicht auf einer Partition des Raid-Verbunds. Das gibt uns im Schnitt mindestens 10% Performance-Vorteile.

Bei der Erstellung des iRST-Raid10-Volumes habe ich mich an die Default-Chunksize gehalten, die die BIOS Funktionen angeboten werden.

Default Chunk-Size des iRST: 32 KB

An dieser Stelle mögen die Daten des Test-Tools "gnome-disk" genügen. Ich zeige hier Daten für Lese/Schreib-Zugriffe für relativ große sog. "Meßwertgrößen" - was immer das genau bei dem Test intern bedeutet. Aus bestimmten Gründen glaube ich nicht, dass es sich um die Blocksize handelt, mit der die Datenmenge der "Meßwertgröße" geschrieben wird; das verträgt sich nicht mit Daten aus anderen Tests. Aber im vorliegenden Artikel kommt es mir ja nur auf relative Verhältnisse an.

Die untersuchten Partitionen waren in beiden Fällen mit LVM erstellt worden, wenn nichts anders angegeben ist.

Differenziertere und genauere Tests, die ich später mit dem Tool "fio" durchgeführt habe, ändern übrigens nichts am Ergebnis des hier präsentierten Vergleichs des iRST-Raids gegenüber einem Standard SW-Linux Raid.

Daten für den iRST-Controller - 20 MB "Messwertgröße"
irst_raid_ssdroot_20mb

Daten für ein reines Linux SW-Raid - 20 MB "Messwertgröße"
swraid_ssdroot_20mb

Die bereits hier erkennbare Tendenz etwas höherer Lese- und geringerer Schreibraten wird scheinbar noch deutlicher bei kleineren "Meßwertgrößen":

Daten für den iRST-Controller - 1 MB "Messwertgröße" - nach TRIM
irst_raid_ssdroot_1mb_after_trim

Daten für den iRST-Controller - 1 MB "Messwertgröße" - Sättigung
irst_raid_ssdroot_1mb

Dagegen:
Daten für eine reines Linux SW-Raid - 1 MB "Messwertgröße" - Sättigung
swraid_ssdroot_1mb

Zwischenergebnis:

Die obigen Daten wirken denn doch so, als ob ein reines SW-Raid unter Linux langsamer sei. Der gemessene Unterschied in der Schreibrate von bis zu 100 MB/sec bei 1MB Daten (vermutlich mit deutlich kleinerer Blocksize geschrieben) bei einem Minimalwert von 290 MB/sec wiegt schwer und entspricht einem relativen Unterschied von ca. 34%.

Zudem wird die theoretisch mögliche reine Datenschreibrate einer einzelnen EVO 850 SSD (zw. 300 und 490 MB/s je nach Testsetup und Größe der zu schreibenden Blöcke) durch das Raid-System bereits unterschritten.

Aber ist dieser Befund tatsächlich valide?

iRST-Performance-Vorteile ?

Bringt der iRST-NModus des Intel SATA-3-Controllers gegenüber einem reinen SW-Raid doch spürbare Vorteile? Nein, das obige Ergebnis täuscht. Nachfolgend die Daten für ein besser eingestelltes SW-Raid-System, das dann mit dem iRST-Array vergleichbar wird.

Bei den nachfolgenden Abbildungen ist zu beachten, dass die Unsicherheit der Daten (u.a. durch nicht getrimmtes Filesystem, interferierende Prozesse im OS) ca. 10 - 20 MB/sec ausmachen kann. Die dargestellten Abbildungen zeigen zufällige und nicht die in Tests zeitweise erreichten maximalen Werte.

Daten für besser parametriertes reines SW-Raid - mit LVM - 20 MB "Messwertgröße"
swraid_ssd_optimiert_20mb_with_lvm

Daten für besser parametriertes reines SW-Raid-Array - ohne LVM - 20 MB "Messwertgröße"
swraid_ssd_optimiert_20mb_without_lvm

Daten für besser parametriertes reines SW-Raid-Array - mit LVM - Chunk Size: 16KB - 20 MB "Messwertgröße"
swraid_ssd_optimiert_16k_20mb_with_lvm

Für die Messgröße 1MB betrachten wir nun mal den Einfluss der sog. Chunk-Size des Arrays etwas genauer:

Daten für ein besser parametriertes reines SW-Raid-Array - ohne LVM - Chunk Size: 512KB - 1 MB "Messwertgröße"
swraid_ssd_optimiert_512k_1mb_without_lvm

Daten für ein besser parametriertes reines SW-Raid-Array - mit LVM - Chunk Size: 64KB - 1 MB "Messwertgröße"
swraid_ssd_optimiert_64k_1mb_with_lvm

Daten für besser parametriertes reines SW-Raid-Arrays - mit LVM - - Chunk Size: 32KB - 1 MB "Messwertgröße"
swraid_ssd_optimiert_32k_1mb_with_lvm
 
Die letzten Bilder deuten bereits an, dass die Chunk-Size eines Raid-Arrays gerade bei kleineren Datenblöcken offenbar einen größeren Einfluss auf die Performance - und im besonderen die Write-Performance - hat. Wir kommen hierauf in detaillierterer und systematischer Weise in einem späteren Beitrag zurück.

Der Einsatz von LVM als Zwischenschicht zwischen Partitionen und Filesystem der LVM-Volumes fällt dagegen kaum ins Gewicht.

Ich darf an dieser Stelle verraten, dass für die Annäherung an die bzw. das Übertreffen der iRST-Werte genau eine kleine Änderung bei der Erstellung des SW-Raids eine wesentliche Rolle spielte. Siehe hierzu einen der nächsten Beiträge in dieser Serie.

Ist der Einsatz des iRST-Modus des Intel Z170-SATA3-Controllers notwendig für SSD-Performance?

Die Antwort auf Frage ist Nein. Die obigen Daten belegen, dass Performance-Aspekte keinen Grund für oder gegen den Einsatz des iRST-Modus darstellen. Sie sprechen eher für den Einsatz eines reinen SW-Raid-Systems unter Linux: Richtig konfiguriert, erreicht man bei den Schreibraten mindestens die Werte des iRST und in der Leserate übertrifft man sie regelmäßig.

Kein Argument für oder gegen den iRST-Einsatz stellt aus meiner Sicht zudem die CPU-Belastung dar. Ich konnte keine substanziellen Unterschiede erkennen. Auf einem Linux-System mit 4 CPU Cores (i7 6700K) und Hyperthreading ist die CPU-Belastung für die 8 CPU-Threads außerhalb von (Re-)Sync-Phasen in der Praxis unerheblich, solange nicht viele große Raid-Verbände angesteuert werden müssen. Die Raid-Behandlung (Striping etc.) erfolgt in aktuellen Kerneln (seit 3.12) zudem multi-threaded.

Ist der iRST notwendig für Boot-Unterstützung und Grub2 auf einem reinen Linux-System?

Die Frage ist eigentlich nur für den Fall relevant, dass man das OS auf dem Raid-Array selbst installieren will. Was ich - wie oben erläutert - für keine gute Idee halte. Aber selbst dann ist die Antwort Nein.

Das Aufsetzen des Systems ist im Falle eines reinen SW-Raids nur ein wenig komplizierter - und es sind ein paar Regeln zu beachten:

  • Die efi-boot- Partition darf aber nicht Bestandteil einer Linux-LVM-Gruppe an Partitionen werden. Das erscheint logisch: Linux muss schon da sein, um LVM z.B. von einem initRAMFS aus zu nutzen. Die Grub und efi-Informationen werden aber vorab ausgewertet und müssen ohne LVM zugänglich sein.
  • Die efi-Boot-Partition darf nicht Bestandteil des reinen SW-Raid-Arrays sein. Es gilt eine analoge Begründung wie beim vorherigen Punkt.
  • Ein initramFS mit den notwendigen Treibermodulen ist erforderlich. Aber das wird von den meisten Linux-Installern sowieso ordentlich prepariert.

Das bedeutet in der Praxis, dass ihr die efi-Partition entweder auf eine andere Platte legt, die nicht am Raid-Verbund beteiligt ist. Oder ihr legt auf jeder der Platten, die man z.B. in einen SW-Raid 1- oder Raid 10-Verbund einbinden will, zunächst eine kleine, ca. 170 MB, efi-Partition an, die ihr mit FAT formatiert, aber später eben nicht in das SW-Raid-Array einbindet.

Um Ausfallsicherheit zu gewährleisten, kopiert man später die bei der Installation z.B. auf /dev/sda1 angelegte efi-Partition nach einigen wenigen Änderungen mittels des Kommandos dd auf die vorbereiteten efi-Partitionen der anderen am Raid-Verbund beteiligten Platten. Hinweise darauf, wie man hierbei im Prinzip zu verfahren hat, liefert etwa der folgende Artikel, der sich von Ubuntu auf andere Linux-Varianten verallgemeinern lässt:
http://askubuntu.com/questions/660023/how-to-install-ubuntu-14-04-64-bit-with-a-dual-boot-raid-1-partition-on-an-uefi
Grub2 in der efi-Variante schreibt die notwendigen Infos in die efi-Partition. Das muss allerdings so geschehen, dass die root-Partition auf dem Raid-Systen in neutraler Weise angesprochen wird.

Der iRST-Controller macht bzgl. der efi-Partition das Leben etwas einfacher: Da der iRST-Controller für UEFI-Systeme Boot-Unterstützung (Zwischenschicht) liefert, kann die efi-Boot-Partition dann auch auf einer Partition des vordefinierten Raid-Arrays eines imsm-Containers installiert werden.

Allerdings ist das "iRST/efi/grub2"-Geschäft manchmal auch mit unerwarteten Falltüren versehen:

Ein spezieller Fall ist der, dass man ggf. im Zuge einer OS-Installation auf dem iRST-Raid-System die Grub-Informationen von vornherein nicht auf eine spezifische neue Partition hat schreiben lassen - sondern einen Grub-Eintrag auf einer bereits existierenden efi-Partition (auf einer anderen Platte) mit den neuen Informationen überschrieben hat. Hat man dann keine weitere Partition mit einem gültigen grub-Eintrag mehr, so führt eine anschließende Auflösung des iRST-Raid-Containers offenbar ins Boot-Nirwana.

Selbst wenn man auf anderen Platten noch gültige Grub-Boot-Einträge haben sollte, so muss man im Bios zunächst auf den AHCI-Modus umstellen (Storage-Einstellungen), um diese alten gültigen efi-Boot-Einträge überhaupt finden zu können. Hier wird die iRST-Zwischenschicht offenbar auch mal zum Verhängnis. Ein Grund mehr, von vornherein nicht auf den iRST zurückzugreifen.

Also: Bevor man Experimente mit dem iRST-Raid macht, vorab einen gültigen Grub-Boot-Eintrag für ein anderes Linux OS auf einer anderen Platte erstellen lassen. Die entsprechende efi-Partition mit ihren Grub-Informationen bei den kommenden Experimenten NICHT überschreiben, sondern eine andere, vorbereitete efi-Partition verwenden. So kommt man wenigstens immer und auch nach Auflösung des RAID-Verbundes wieder in ein gültiges System.

Folgende Ratschläge gelten aber auch bei Einsatz eines reinen Linux-SW-Raids:

  • OS-Anlage außerhalb des Raids.
  • Wenn ihr dennoch unbedingt einen Raid-Verbund mit OS auf dem Raid betreibt, so sorgt dafür, dass ihr ein 2-tes boot- und lauffähiges OS auf einer separaten Platte (außerhalb des Raid-Verbunds) verfügbar habt. Legt auf dieser Platte (außerhalb des Raids) ebenfalls eine funktionierende efi-Partition an. Schreibt dann vom sekundären OS einen funktionierenden Bootloader-Eintrag in genau diese efi-Partition.
    Kurz gesagt: Sorgt dafür, dass ihr eine gültige efi-Partition mit gültigen Grub-Einträgen auch außerhalb der am Raid beteiligten Platten habt. Definiert dann die Boot-Prioritäten im Bios. Viele UEFI-BIOS suchen bei Problemen automatisch die nächste valide efi-Partition. Ansonsten sollte man immer ein gutes Linux-Live-System parat haben.
  • Vergesst nicht, dass gerade bei SSDs der zunehmende gleichmäßige Verschleiß der Platten im Raid-Verbund die Wahrscheinlichkeit eines parallelen und zeitlich kurz hintereinander getakteten Ausfalls mehrerer Platten erhöht. Macht also von allem regelmäßig Backups. Das erspart einem im Ernstfall viel Ärger.

Gegenargumente gegen den Einsatz des Intel RST Controllers auf reinen Linux-Systemen

Es gibt aus meiner Sicht folgende valide Gegenargumente gegen den Einsatz des iRST-Controllers:

  1. Im Kern handelt es sich auch nur um ein SW-Raid. Ich konnte nach geringfügigen Optimierungs-Maßnahmen keine Performance-Vorteile erkennen.
  2. Reduzierte Flexibilität: Bei Einsatz des Fake-Raid-Contollers geht einem im Vergleich zu den Konfigurationsmöglichkeiten von SW-Raids viel, viel Flexibilität verloren. Das sollte man in der Praxis nicht unterschätzen. So lässt der iRST genau 2 Raid-Arrays (Volumes) per Container zu - und der zweite anzulegende Verband kann dann in seiner Kapazität nicht mehr begrenzt werden. Er wird den gesamten verbliebenen Platz der bereits einander zugeordneten Container Platten beanspruchen.

    "mdadm" unter Linux erlaubt dagegen die Erstellung beliebig vieler, in ihrer Größe definierbarer Arrays über gleiche oder unterschiedliche SSDs, genauer Partitionen, hinweg - und auch solche exotischen, aber performancesteigernden Dinge wie etwa ein Raid 10 über Partitionen von nur 2 SSDs! Die Kapazität eines jeden einzelnen Arrays darf dabei über den Platz der genutzten Rohpartitionen frei festgelegt werden.

  3. Die fehlenden Freiheiten bzgl. der Größenbegrenzung des zweiten Arrays hat bei bestimmten Raid Levels, besonders aber im Fall von großen Raid-5- oder Raid-6-Arrays ergebliche Auswirkungen für evtl. Wiederherstellungsverfahren:
    Legt man wegen Punkt 1 zwangsweise ein iRST-Volume mit großer Kapazität an, so wird das Raid-Array bei irgendwelchen Problemen mit darauf aufgesetzten Filesystemen immer als Ganzes einer Resynchronisation unterworfen. Das passiert z.B. nach unsauberen Shutdowns, bei denen Filesysteme des Raid-Verbandes nicht mehr abschließend mit Caches synchronisiert werden konnten. Fällt gar eine Platte aus, wird der gesamte Container mit beiden Arrays rekonstruiert.
    Das kostet bei allen Raid-Formen erhebliche Zeit - vor allem aber für Raid 5/6-Arrays. Die SSD-Geschwindigkeit hilft zwar, aber bei großen Arrays mit > 1 TB Kapazität zehrt das im Falle von Raid 5 trotzdem an den Nerven. Im Falle von RAID 5 wird dabei der Verschleiß der eingebundenen SSDs erheblich beschleunigt. Mehr dazu im nächsten Beitrag.
  4. Für Raid-5-Arrays unterstützt der aktuelle Z170-iRTS Controller (Version 14 der Firmware) nicht das Absetzen eines TRIM-Befehls [fstrim -v /MOUNT-VERZEICHNIS-EINES-FILESYSTEMS-DES-RAIDS]. Das wird nach einiger Zeit und im Besonderen auf kleineren Partitionen des Raid-Verbands zu Performance-Problemen führen. Das ist in der Praxis für viele SSD-Typen und auch die EVO 850 tatsächlich nachweisbar.
  5. Die Größe eines iRST-Raid-Arrays kann durch Hinzufügen von weiteren Partitionen im Nachhinein wohl nicht mehr verändert werden. Bei einem reinen SW-Raid unter Linux ist das aber über ein paar Schritte möglich (s. die mdadm-Literatur).
    Für einen imsm-Container ist mir das bislang mit Linux-Bordmitteln dagegen nicht gelungen. So war es mir u.a. nicht möglich, auf Platten, die bereits einem RTS-Verband im "imsm"-Format zugeordnet waren, neue Partitionen anzulegen, die ich einem bereits definierten imsm-Volume hätte zuordnen können.
  6. Bei einem Ausfall des iRST-Controllers oder des Mainboards benötigt man ein neues Mainboard-Board mit iRST-Funktionalität, um wieder an die Daten des Arrays zu kommen. Im Falle eines SW-Raids aktiviert man dagegen auf einem anderen Linux-System die md-Raid Module und hängt dann die SSD-Platten an die dort verfügbaren SATA-Controller. Und schon hat man wieder Zugriff.

Gegen den oben genannten Punkt 3 gibt es zwar begrenzte Mittel (sog. Bitmaps; siehe einen kommenden Beitrag) - aber die reduzieren nach meiner Erfahrung spürbar (!) die Write-Performance. Und Bitmaps helfen nur so lange, soweit noch alle Platten mit funktionierendem Filesystem vorhanden sind. Sie helfen nicht im Falle eines degraded Arrays, bei dem eine Platte ausgefallen ist.

Weitere Gründe, die gegen den Einsatz des iRST auf reinen Linux-Systemen sprechen, findet ihr hier:
http://superuser.com/questions/461506/intel-matrix-storage-manager-vs-linux-software-raid
Siehe dort auch die Diskussion.

Gibt es auch Gründe für den Einsatz des iRST?

Mir fallen dazu nur folgende Punkte ein:

  • Die Restaurierung bzw. Resynchronisation eines defekten Raid-Verbunds mit einer Ersatz-SSD lässt sich zur Not auch unabhängig vom Betriebssystem - nämlich über BIOS-Funktionen - durchführen. Dies ist im Besonderen dann zu bedenken, wenn man das Betriebsystem und/oder die efi-boot-Partition selbst auch unbedingt auf dem Raid installiert hat.
  • Auf Dual-Boot-Systemen (mit Windows) bringt das Intel-spezifische "imsm"-Format Vorteile. Der Raid-Verbund selbst und entsprechend formatierte Partitionen können auch von MS Windows aus angesprochen werden.

Genug für heute. Im nächsten Artikel

SSD Raid Arrays unter Linux – III – negative Aspekte von Raid-5-Arrays

möchte ich begründen, warum ich iRST- oder SW-Raid-5-Arrays für SSDs unter Linux für keine gute Idee halte.