SSD-RAID: Billig-Arrays oder SSD-Laufwerke?

Hab ich es übersehen oder warum wird auf den Hauptkritikpunkt bei SSD Raids nicht eingegangen.
Was ist mit der Trim unterstützung im Raid 0? Das ist die Frage, die über allen stehen sollte. Hält ein Raid 0 auch nach langen Schreibzyklen seine Leistung?
Bei intel fehlt die Raid 0 Unterstützung mit Trim immernoch im Storagetreiber.

Bei AMD auch

Wobei die Platten Dank interner Garbage Collection auch ohne Trim überlebensfähig sein dürften.

Langsam wirds langweilig. Die Intel G2 160GB rockt in den Anwendungen immernoch. Wann endlich kommt ein würdiger Nachfolger. Der wird wohl Intel G3 heißen...

Zum Test selbst, Irgendwie eine Schnappsidee, einen RAID Controller vor die performanten SSD Controller zu schalten. Jetzt ist es schwarz auf weiß bzw. bunt auf weiß, also amtlich

Raid Test der Zweite!
Jetzt funktoniert die Garbage Collection im Raid Verbund auf einmal?
http://www.tomshardware.de/foren/2 [...] ce-analyse

Also ich behaupte, das auch die I/O-Leistung bei einem Desktop wichtig ist, wichtiger als die Datentransferrate. Es finden auf einem Desktop fast ausschliesslich Zugriffe auf kleine Dateieen oder Zugriffe auf Bereiche von Dateieen statt. Sequentielle Zugriffe sind bei einem Desktop eine Seltenheit. Wer Spiele spielt profitiert ebenfalls eher von I/O-Leistung als von Datentransferrate. Fast alle Spiele arbeiten Scriptgesteuert und laden hunderte winzige Dateieen und/ oder winzige Datenbloecke ein. Blizzards und Valves Spiele bestehen aus MPQ oder anderen Archiven, bei denen staendig kleine Bloecke ausgelesen werden. Bei Valve ist es dann auch noch so, das dort viele kjleine Scripts und Config-Dateien angelegt und bearbeitet werden muessen. Da bringt einem Datentransferrate nichts. Erst mit SSDs konnte ich bei CSS innerhalb weniger Sekunden einen Server joinen. Mit meinbem SCSI-RAID brauchte ich trotz 200MByte die Sekunde max wesentlich laenger. Das Starten der Spiele dauert auch keine 5 - 10 Sekunden, wo man vorher 20 - 30 Sekunden warten musste.

ich hätte ein Raid-Array aus 4x 40er Sandforce SSDs irgendwie spannender gefunden, als von den alten Kingstons von der Resterampe...
4x 40er Sandforce sind nicht so viel teurer, dürften aber grade bei der IO-Performance alles andere weit hinter sich lassen...

Bitte setzt euch bei eurer Analyse mit den Clustergrößen des Dateisystems, der Stripesize des Raids und Partitionalignment auseinander. Versucht dabei das ganze so einzurichten, dass die Cluster nicht die Grenzen der Stripeblöcke überschreiten (also ein Cluster nicht auf zwei SSDs verteilt ist) und schaut welchen Einfluss es hat wieviel Cluster man in einen Block des Raids packt. Die großen Einbrüche scheint es vorallem dort zu geben wo eure Benchmarks auf den Umweg über das Dateisystem angewiesen sind. Während Windows 7 die Alignmentgeschichte bei einzelnen SSDs idR automatisch hinzubekommen scheint, schafft es das bei Raidkonfigurationen nämlich definitiv nicht (immer).

Falls ihr euch mit dem Thema schon auseinandergesetzt habt dann dokumentiert das bitte für den Leser.

Edit: Wobei ein Großteil der Performanceeinbrüche wohl schon daher kommt dass die Billigssd einzeln schon extrem mies ist

finde die alten kingstons für den test hier auch ein griff ins klo.
Wer performance-enthusiast ist, der wird sich diese dinger nicht holen!
Lieber 2, 3 oder 4 SSDs zu 60GB mit SF-1200 (Z.B. Vertex 2). Und dann bitte an einem hardware RAID-controller (SAS-sektion) mit eigenem Onboard Cache!

@holgiheftig

Die dedizierten Raidcontroller erhöhen im Vergleich zu den Onboardcontrollern die Zugriffszeit bei SSDs leider signifikant.

hast du quellen hierzu?

Brauchts nicht, ist einfach so. Wird dir jeder Benchmark mit Hardware-RAID Controllern aufzeigen und ist auch logisch. Bei einem Software-RAID muss der verbaute SATA/ SAS/ Wasauchimmer-Controller einfach nur die Datenrate fuer das Laufwerk packen koennen. (Die E/A-Performanz ist bei solchen Controllern normalerweise nicht beschraenkt) Jeder aktuelle Controller sollte das packen... Dann ist der Rest ziemlich wurscht, wenn deine Systemleistung den vollen Durchsatz hergibt. Bei einem Hardware-RAID bist du aber an den verbauten Co-Prozessor gebunden und dessen Cache-Funktion. Der Windows-Schreibcache wird dann naemlich abgeschaltet. (Aus gutem Grund) Und der Coprozessor ist von seinem eigentlichem Datendurchsatz ebenfalls beschraenkt. Je nach dem, welche Funktionen genutzt werden, wird der Controller immer langsamer. Ist der Controller aufgrund sehr schneller Laufwerke an der Leistungsgrenze, kann das Abschalten von eigentlich Performanzerhoehenden Funktionen sogar wieder die Leistung erhoehen, da der Verwaltungsaufwand sinkt. Read-Ahead wuerde ich bei maessigen Datentransferraten z.B. als Erstes deaktivieren.

Dadurch wird ein HW-RAID in Sachen I/O und maximalen Datendurchsatz bei sonst vergleichbarem System immer langsamer sein, besonders wenns um SSDs geht. Zumindest dann, wenn das Host-System genug Leistungsreserven hat. Ist der Host auf Dauerlast, sieht es gleich wieder anders aus.

Danke für diesen detaillierten und kompetenten Artikel. Einer der Lichtblicke in letzter Zeit! Daumen hoch und weiter so!

OK!

Im Performance-Vergleich zu dem hier getesteten Onboard-Controller im Software RAID 0: wie steht es mit der Windows Lösung "Stripesetvolume als Dynamischer Datenträger"?

Interessanter Bericht aber ihr macht den gleichen Fehler wie alle:

Unter Windows schaltet man SSDs mittels des Windows-RAID zusammen da so die Trimm-Funktionalität durch die Blocklayer vererbt wird. Oder wenigstens sollte, für Win7 wars angekündigt.

Und ach was mußte ich lachen wie lahm Windows mit SSDs ist... unter Linux (nichts aber BSD und MacOx) kann ich ein Filesystem sauber an der Zellengrösse eines Flashbausteins ausrichten und mit optimierten Supersektoren passend zur Hardware arbeiten lassen. Oft verwenden SSDs intern 128 bis 1024kByte grosse Zellen, passend drauf zugreifen bringt ENORM viel. Ausserdem kann man Features wie Lazywrites und noatime dazu mißbrauchen die wirklich lahmen Schreibzugriffe massiv zu reduzieren. Und von einem gepatchtem Updated rede ich noch garnicht.

Dadurch wird eine schnelle SSD nicht unbedingt viel schneller aber eine langsame oft ganz massiv.

Bei Bonnie z.B. erreicht die €20 8MB-Zweit-SSD meines EEE rund 30% IO-Leistung der 120GB X25. Ja, richtig, das kleine Mistding was unter Windows so lahm seekt wie ein Floppylaufwerk.

Das intelligente Einsparen von kleinen Read-Modify-Write bringt bei einfachen SSDs mal schnell die 20fache Schreib- und doppelte Lesegeschwindigkeit.

Einen Teil kann man auch unter Windows nutzen da man z.B. eine alignte, mit passenden Stripe- und Stride-Grössen formatierte Ext2-Partition auch unter Windows nutzen kann. Schade daß man das Ext2-Filesystem unter Windows nur für Daten und nicht zum Booten verwenden kann.

Windows bleibt einfach ein Mickey-Maus OS.

Och bitte geh wieder ins tiefe schwarze Loch...

FDISK/ Diskpart kann schon seit Ewigkeiten die Partition so hinschieben das ein Block auf Sektor passt.

Und Linux ist ja wohl ein Lacher! Weder hast du immer die vernuenftigen Treiber fuer spezifische Controller, noch ist die Performanz besser. War es nicht so, das Linux mit 4K Pages arbeitet und beim Swappen dann "sehr effizient" alles mit 4K-Bloecken zur Festplatte spuckt, oder irre ich da? Ohne Frickeln ist Linux in der Hinsicht Gruetze.

Was bringt es noch mal den Zugriff so auszurichten, das eine "Flashzelle" komplett ausgelesen wird? Garnichts?! Wenn du die Partition korrekt ausgelegt hast ist es der SSD schnurzegal! Entscheidend ist welche Blockgroeße beim Auslesen verwendet wird. Zudem koennen FAT und NTFS auch groeßere Cluster anlegen. Kein Problem.

Und an deiner Stelle wuerde ich von Schreibcache-Einstellungen die Finger lassen. Zudem hat Windows dafuer einer sehr ausgefeilte Caching-Artchitektur, die sich wenigstens noch durch den Controller zwangsabschalten laesst. Habe schon ein paar schlaue Linux- Admins gesehen, die bei nem Hardware-RAID den Write-Cache des Betriebssystems angelassen haben. Da nuetzt die BBU auf dem Controller bei nem Chrash auch nx mehr.

Und die I/O-Leistung mit verfrickelten Software-Write-Cache Einstellungen zu benchen ist genauso schlau wie lachend in eine Kreissaege zu huepfen. Im realen Umfeld bleibt von den Zahlen nicht mal ein warmer Pups uebrig.