RAID-Controller mit RAID 5 ~ 100 Euro

[Ernst@at]

Warum? Drei Platten sind Minimum, ich kann ein Raid 5 auch mit 50 Platten aufbauen, was meinst du was dann abgeht? Da kommen IOPs und Übertragungsraten zustande, davon träumt jede SSD.

Das einzige, was hier träumt, bist Du.
Es geht um performante Schreibraten, weil die bei RAID5 allgemein beschissen sind; die sind bei 50 Platten genauso im Keller wie bei 4,6,7, oder 8 Platten. Lies doch mal, was ich hinterher dazu geschrieben habe und versuch das zu verstehen, bevor Du mit IOPS um Dich wirfst.
Daran kann auch kein HW-RAID Controller etwas ändern.

 

[Dr. MaRV]

Warum dann die pauschale Aussage, dass es nur mit 3 oder 5 Platten performant ist? Viele Spindeln bringen nun mal Performance und damit einhergehend entsprechende IOPs und Übertragungswerte, das hat nichts mit träumen zu tun.
Und niemand erwartet, dass ein kleiner Desktop Raid Controller mit einer NetApp oder EMC² mithalten kann. Alignment und Clustergröße ist bei allen Datenträgern wichtig, egal ob nun konventionelles Laufwerk mit rotierenden Plattern oder Flash-Speicher.

 

[Holt]

Aber natürlich schaffen in den meisten Situationen die onboard Controller relativ zufriedenstellende Datenraten. Ich hatte allerdings schon Situationen (gerade bei Backups) wo mein onboard Raid 5 drastisch in der schreibleistung eingebrochen war wenn mehrere Lese- und Schreiboperationen gleichzeitig stattfanden.

Das ist ja klar, denn da müssen sich die Köpfe laufend bewegen, weil überhaupt nicht so viel Cache vorhanden ist wie bei HW RAID Controllern üblich. Ohne den Cache fällt die Leistung alles HDDs bei parallalen Zugriffen aufgrund der ständigen Kopfbewegungen immer massiv ab. Das ist ja gerade das, wo die SSD ihren Hauptvorteil haben.

Das kleine Geheimnis dahinter ist, dass Win in der Clustergröße-max 64K die I/O's absetzt

Wie wo was? Windows setzt gewöhnlich I/O über so viele LBAs ab, wie im Shunk des Files zusammenhängenn und maximal in den Puffer passen, was gewöhnlich 128/256 kB sind, oder ist das bei RAID sogar weniger?

Viele Spindeln bringen nun mal Performance und damit einhergehend entsprechende IOPs und Übertragungswerte, das hat nichts mit träumen zu tun.

IOPS bekommt man, wenn auf viele Platten parallel zugeriffen werden kann, gute Übertragungsraten wenn die Daten über viele Platten verteilt sind. Beides steht sich also bei der Auslegung des RAID entgegen und da HDDs bestenfalls nur ein paar Hundert, SSD aber viel 10.000 IOPS packen, schlägst Du mit 50 HDDs also niemals die IOPS einer performante SSD, sofern Dir der Cache da nicht zur Hilfe kommt, aber dessen Kapazität ist garantiert deutlich geringer als die einer SSD.

 

[Ernst@at]

Wie wo was? Windows setzt gewöhnlich I/O über so viele LBAs ab, wie im Shunk des Files zusammenhängenn und maximal in den Puffer passen, was gewöhnlich 128/256 kB sind, oder ist das bei RAID sogar weniger?

Das hat mit RAID rein gar nichts zu tun und ist bei NTFS-Fileszugriffen aller Windows-Versionen, die ich kenne, so. Vielleicht hast Du aber eine Special Edition.

Zur Ergötzung sieh Dir so wie hier mal einen Kopiervorgang im Win7 auf eine Einzelplatte an. Wenn Du im Mikrokosmos der Platten-I/O's im Log einen findest, der mehr als 65536 Bytes(oder 128 Sektoren) lang ist, dann hast Du recht.

Warum dann die pauschale Aussage, dass es nur mit 3 oder 5 Platten performant ist? Viele Spindeln bringen nun mal Performance und damit einhergehend entsprechende IOPs und Übertragungswerte, das hat nichts mit träumen zu tun.

Mein Post nicht gelesen oder nicht verstanden?
Pauschal würde es 2^x+1 heißen, womit 3,5,9,17,33,65... in Frage kommen, weil dann 2^x Datenstripes und ein Paritystripe je Stripeset vorhanden sind. Ich antworte hier auf einer spezielle Anfrage für einen Controller mit 8 Ports(bzw einen onboard mit 6) zum Thema Performance bei seqentiellem Schreiben, womit die Zahlen über 5 wegfallen
Nachdem 64K =128(oder 2^7)Sektoren nicht unter eine Mindestgranularität der möglichen Stripsizes(bei AF Platten auf 4K limitiert) zerteilt werden kann, ist praktisch bei 16 Stripes je Stripeset Schluss, womit über 17 dieser Trick nicht mehr wirksam ist und in jedem Fall vor dem Schreiben gelesen werden muss, was dann selbst bei rein sequentiellen Anforderungen ohne Störung durch andere Aktivitäten die Übertragungsrate in einstellige MB/s-Bereiche drückt.

 

[Humptidumpti]

Ja. Und jetzt bitte wieder @Topic. Wenn Controller dann möglichst günstig. Empfehlungen bitte.

 

[Holt]

Zur Ergötzung sieh Dir so wie hier mal einen Kopiervorgang im Win7 auf eine Einzelplatte an. Wenn Du im Mikrokosmos der Platten-I/O's im Log einen findest, der mehr als 65536 Bytes(oder 128 Sektoren) lang ist, dann hast Du recht.

Auch wenn es Off-Topic ist und ich Dir ungerne widerspreche, aber die S.M.A.R.T. Werte der Crucial M225 (mit Vertex Turbo Firmware) im Dauerschreibtest auf http://www.xtremesystems.org widerlegen Dich klar:


Der Indilinx ist alles andere als ein toller SSD Controller, aber er hat sehr ausssagekräftige S.M.A.R.T. Attribute:
C7: 1772554038742 Write Sektors
Das sind jeweils 512 Byte, was 845219.6GiB entspricht wie SSD Life anzeigt und was auch dem Testprogramm entspricht.
C9: 8292483458 Wrtie Commands
Teile ich nun den Wert von C7 durch den von C9 so komme ich auf 213,75 Sektors die pro Write Command geschrieben wurden oder eben 107kB.

 

[Ernst@at]

Und? Wie widerlegt das meine Aussage, das WINDOWS Fileoperationen (Copy, Move) mit max 64K ablaufen?
"So, 1/3 of the drive is filled with static data (W7 x64) an the rest is used for writes. The app fills the drive with random sized files ranging from 1KB up to 12MB in size."
Jede App die vernünftig programmiert ist, macht das natürlich besser, wie auch jeder Benchmark, zB HDTune. Deswegen ist die Enttäuschung groß, wenn dann im normalen Betrieb die Schlafkrankheit am RAID5 ausbricht, wenn man Daten draufschaufelt.

Legt man das RAID5 richtig an, wie oben erwähnt, dann kann man auch mit einem onboard-RAID5 durchaus SSD-ebenbürtige Transferraten im normalen Betrieb beim seq. Beschreiben erreichen, ohne einen extra Zusatzcontroller zu benötigen.

 

[Holt]

HD Tune schreibt in der Standardeinstellung nur alle paar MB bzw GB einen Block von 64k, welche Puffergröße der Windows Explorer beim Kopieren verwendet, weiß ich nicht, aber die S.M.A.R.T. Werte belegen, dass auf die SSD mit Zugriffen von durchschnittlich 107kB geschrieben wurde, 64kB ist also nicht das Limit beim Adressieren zusammenhängender Shunks.

 

[Ernst@at]

Das Limit an Datentransfer je I/O ist bei neueren Platten 32MiB, und kann abhängig von der logische Sektorgröße bis 256MiB reichen. Reine Sache der Applikation, einen oder mehrer dieser Bereiche zur Verfügung zu stellen. Was nichts daran ändert, dass diese Windows-Fileops seit mehr als einem Jahrzehnt mit max 64KB je I/O dahinsiechen.
Das alte freeware-HDTune war mit 128KB lesend über die Oberfläche unterwegs, beim pro kA.

 

[Holt]

Wie sagt, wie groß die Windows Programme ihre Puffer wählen, kann ich nicht sagen, aber das Testprogramm von Anvil nutzt offenbar 128kB große Schreibzugriffe und das stimmt auch mit den Werten überein, die ich von Windows Systemfunktionen ausgelesen habe. Das HDTune 64k schreibt, kommt von tweakpc, ich selbst nutzt das Programm nicht.