neues Raid5 in Planung, welche SSDs?

[EspE]

moin,

hitman the onkel of OCZ,
sonst ka warum du OCZ empfehlen tust

ansonsten ich hab auch ka wie der kontrolelr im raid 5 oder 1 oder 0 oder 10 läuft,
weil ich noch keine ssds dafür hab.
ja und btw, der Ctrl. wird auch erst morgen oder übermorgen geliefert
***ja ka, viell. hab ich echt den falschen genommen, wird sich aber noch zeigen***


BTT.: ich wollt eigentlich nur eine epfehlung für gescheite SSDs die im Raid5 gut klar kommen.
Vorallem auch mit einbeziehung der neusten Modelle!
soweit tendiere ich tatsächlich dazu meine eine 830er durch mein ST-NX01 Replikator zu jagen

 

[Holt]

ja, meinste die 830?
die scheint bisl wenig IOPS leistung zu haben.
vom ding her gefallen mir die kngston irgendwie besser, ka. ich google noch bisl....

Wenn Du die Angaben von SSD mit Sandforce ernst nimmt, ja. Aber wenn Du mal darauf achtest, wie es sich bei den Messungen verhält, wie die Werte sich unterscheiden wenn über 8GB oder 85% der Kapazität gemessen wird und was für eine Komprimierbarkeit die Testdaten der verwendeten IOMeter Versionen haben, über welchen Adressbereoch AS-SSD bencht, etc., dann könnte es anders aussehen.

Aber wozu fragst Du, wenn Du die Ratschläge ignoriert? Außerdem solltest Du für ein RAID in jedem Fall möglichst zuverlässige SSDs verwenden und das ist die 830er auf jeden Fall. Wenn Du das ganze nur zum Rumspiele oder Angeben bauen willst, dann ist das aber ja auch egal, oder? Dann kannst Du es wie OCZ beim Revo machen und ein paar SF mit lahmen async. NAND in ein RAID 0 packen und wirst mit allen Benchmarks die extrem komprimierbare Daten verwenden auch tolle Ergebnisse vorzeigen können. Wer keine Ahnung hat, der lässt sich davon sogar beeindrucken.

 

[EspE]

yo, bleiben wir doch bei Raid5
Raid0 ist mir zu riskant, falls ein SSD ausfällt und Raid10 zu sicher, da ich eh noch externes Raid1 hab.

Ja gut, ok. KP warum sowas überhaupt angeboten wird,
also was für anwendungen profitieren denn von einem Raid?

mfg

btw.: ich ignoriere keine ratschläge, aber vieles davon hab ich schon wo anders gelessen
und sowieso schon mal mit raid0,1,5 experimentiert, auch wenn ohne super ctrl. undmit hdds

 

[Onkelhitman]

also was für anwendungen profitieren denn von einem Raid?

Da liegt einzig und allein dein Fehler. Du hast keine Anwendungsmöglichkeit und weiss gar nicht wofür du das Raid überhaupt benutzt. Vor allem da du ja sowieso ein Raid-1 (warum eigentlich?) zum Daten sichern hast. Daher kannst du dann eben auch die billigsten SSD nehmen und im Raid-0 zusammenschalten.

Du hast also weder Ahnung von Raid, noch Ahnung vom Controller, noch Ahnung von beiden kombiniert. Wie soll man dir daher eine gescheite Antwort geben. Und vor allen Dingen hast du dann auch noch einen Controller ohne Cache genommen. Wenn du wenigstens, anstatt 4 SSD kaufen zu wollen im Raid-5 einfach nur einen Controller mit Cache und 3 SSD genommen hättest. Dann hat der Controller wenigstens noch Dampf hinter. Aber was du da versuchst entzieht sich einfach meinem Verständnis. Und daher kann man dir eben auch leider keine vernünftige Antwort geben.

 

[EspE]

1. warum ich meine daten extern auf einem Raid1 sichere?
2. zu meinen anwendungen hab ich doch gesagt; Video/Photoshopen/Audio/3D
3. weil ich aus einer kurzschlußreaktion einen ctrl. ohne cache zum halben preis kaufe,
bedeutet das nicht dass ich keine ahnung habe.
4. kann ich den ctrl. noch wechseln!
5. boot speed is mir schnuppe, ich boote idr. nur einmal am tag!

 

[DunklerRabe]

Doch, eigentlich heisst es genau das. Du weisst nicht was du da machst. Klar, ne nette Spielerei ist auch mal toll. Aber vernünftige Hilfestellung leisten kann man dann nicht.
Vielleicht solltest du dir meinen letzten Post doch mal zu Gemüte führen, hast du bisher wohl nicht getan.

 

[Onkelhitman]

Video gucken? Photoshop JPEG's bearbeiten, Audios hören, 3D-Benchmarks angucken?
1. Warum Raid-1?
3. Nein es bedeutet nur, dass du kaufst weil dort: "Angebot! Angebot!" steht. Du hättest dir auch nen neuen Prozessor kaufen können um dann zu fragen was du damit machen sollst.
4. Dann hast du den ja umsonst gekauft... wo wir wieder bei 3 wären.
5. Richtig, hab ich auch nicht erwähnt.

 

[HisN]

was ich damit vor hab?
hmm, laß mal überlegen,
also neben dem ultra schnellem boot den ich mir davon erträume

Alleine der Bios-Post vom Controller wird den (wenn überhaupt vorhandenen) Zeitvorteil beim Booten auffressen. Mich hat der lange Post von meinem Rechner (mit 2 Raid-Controllern gut eine Minute bevor es überhaupt losgegangen ist) so genervt, das ich meine SSDs jetzt ganz normal Betreibe, und den Bios-Post dadurch auf nur 30 Sekunden gedrückt habe.

5. boot speed is mir schnuppe, ich boote idr. nur einmal am tag!

Okey, vielleicht sollte man doch noch die Beiträge auf der 2. Seite lesen, damit man seine Zeit nicht umsonst investiert, weil der TE seine Meinung sprunghaft ändert^^.

Persönliche Erfahrung: SSD Raid0 bringt aber der 2. SSD keine merklichen Veränderungen mehr im Normalbetrieb. Nur beim Handling mit großen Dateien. Und das bricht natürlich spätestens dann zusammen wenn alle Zellen ein mal beschrieben worden sind, weil ja kein Trim über den Controller funktioniert. D.h. das ganze Ding wird Dir dann gut 20% einbrechen beim schreiben.

Ausprobiert an einem Areca2010 mit 256MB Cache

Vielleicht mal die schönen CB oder HWLUXX-Reviews über die Revos lesen (nix anderes baust Du Dir da zusammen). Im Alltagsbetrieb manchmal sogar langsamer als Single-Normalo-SSDs.

Ich würde ja vorschlagen auf den Controller zu verzichten und die Daten/Programme sinnvoll über die Laufwerke zu verteilen, oder gleich eine große SSD zu kaufen.

 

[EspE]

wenn ich auf den ctrl. verzichte dann hab ich nur sata2, zumindest bis irgendwann haswell kommt.

meine angaben über die verwendung in meinen anwendungen waren ja zu erst nicht angegeben,
und dann zu meiner belustigung natürlich spaß angaben gemacht.
hallo, wer glaubt denn sowas; firefox, thunderbird, minesweeper xD

ok, also im endeffekt habt ihr wohl recht, aber ich weiß aus meiner erfahrung in der vergangenheit,
dass mir raid0 bei meinen anwendungen durchaus was gebracht hat.
diese leistung wurde aber klar von der ersten ssd die ich hatte in schatten gestellt,
daher alle hdds raus und es wurde stille, lol!

33. ok also meine wahl der 830 ist schon mehrfach bestätigt worden.
34. ich werde mir mal einfach eine oder drei kaufen und dann berichten ob es mir was gebracht hat oder nicht.
35. natürlich kann ich dann auch paar lange balken zum erfahrungs austausch posten oder ein vid für youtube machen

 

[Onkelhitman]

Das hört sich gut an. Denke bitte daran auch mit Programmen vorher und nachher Tests zu machen. Also bitte einmal komplett ohne Controller, einmal mit Controller im Raid-5 und ne Einzel-SSD. Dann kann man sofort erkennen ob es in deinem Fall etwas gebracht hat oder nicht.

Danke dafür schonmal.

 

[Holt]

dann zu meiner belustigung natürlich spaß angaben gemacht.

Hauptsache Du hast gelacht. Ohne eine sinnvolle Anwendung für ein RAID zu haben, vor allem eines aus SSDs, ist und bleibt es Spielerei und/oder Angeberei.

 

[EspE]

mano, wieso gehen die preise grad hoch
ich warte noch ein bisl und werde mir erstmal eine 840 pro kaufen entweder 128oder256, mal schauen.

auf jeden fall wird die dann für das system sein und kein raid drauß gemacht,
und ich denke mal dafür ist der ctrl. schon mal ne gute idee.
das raid werd ich aber trotzdem noch machen, wenn die preise etwas runter gehen.
zumindest aus 2 laufwerken raid0, das kann für video un photoshop nicht schaden.

34. danke das Ihr mich davon abgebracht habt 7 830er oder noch schlimmer 8 v+200er zu kaufen

 

[EspE]

hallo & frohes neues Jahr,

hier nochmal eine Rückmeldung.

Ich bedanke mich nochmal recht herzlich bei euch,
ein raid aus ssds würde zwar wohl ein leistungs boost geben,
allerdings gibt es andere sachen die viedeo und 3D mehr beschleunigen würden (vorallem auch spürbar und nicht nur messbar).
habe mich somit entschlossen in gpus zu investieren.
auch wenn das OT scheint, vielleicht hilft es ja wem der auch sowas vorhat

gruß

 

[Holt]

Hast Du denn jetzt gar keine SSD?

Übrigens hat 3murmeln recht:

Ich würde mich bei Raid-5 fragen, ob die Garbage Collection der SSDs nicht ständig die Raid-5-Paritätsblöcke weglöscht, weil die ja nicht offiziell zum Dateisystem gehören und damit frei sind.
Ich habe das mal mit 3 SSDs vom Typ Corsair P64 probiert und hatte da selbst mit einem teuren 3ware Raid-Controller Probleme, weil die Garbage Collection eben jene o.g. Blöcke ständig weggeräumt hat und damit nie wirkliche Ausfallsichertheit bestand.

Wie wir inzwischen in einem anderen Thread diskutiert haben, hat die P64 hat einen alten Samsung Controller und da hatte Samsung in der Tat eine Idle-GC integriert, die versucht das Filesystem zu interpretieren. Das dies im Zweifel bei RAID, Verschlüsselung oder einer geänderten Spezifikation der Datenstrukturen des Filesystems natürlich nur übel enden kann, habe ich ja schon mal geschrieben.

Allen die diesen Thread in der Suche finden und trotzdem ein RAID aus SSDs bauen wollen, den empfehle ich mal diesen Beitrag als Auswahlhilfe.

 

[EspE]

Hast Du denn jetzt gar keine SSD?

oh bitte, wer kann denn ohne ssd leben?
also ich nicht, hab 3

 

[Ernst@at]

Hi,warten wir mal was ernst sagt!!!

wer ist ernst?

Damit bin wohl ich gemeint. Seh hier nicht so oft rein, weil da naturgemäß RAID eher kein Thema ist und es auch noch keine SSD's >2TiB gibt.

Ich hab jetzt keine Ahnung, wie der TRIM-Befehl genau funktioniert - nehme aber ohne nachzusehen an, wird wie ein read oder write mit StartLBA, #LB den entsprechenden Bereich (eines im Filesystem gelöschten Datenbereiches) abgewickelt wird.
Meine letzte Info war, dass TRIM nicht an RAID's funktioniert.
Wenn das inzwischen nachgereicht worden sein sollte, frage ich mich, wie das überhaupt bei einem RAID5 oder 6 funktionieren soll.

Dass der Controller bzw deren Firmware oder bei Onboard die Treiber in der Lage sind, einen I/O richtig auf die einzelnen Member aufzusplitten, ist keine Frage. Das genauso bei einem Trim zu machen, auch nicht. Bei RAID0 oder 1 kein Problem, aber wie sieht es bei RAID5 mit dem Parity-Stripe aus?

Nachdem ein Trim an die SSD abgesetzt wurde, ist der ursprüngliche Inhalt nicht mehr vorhanden. Liest man einen getrimmten Block, kriegt man 0x00en zurück.
Daher müsste die RAID5 Logik den früheren Inhalt der zu trimmenden Einzelbereiche und der zugehörigen Parity erst einlesen, XORen und dann die neue Parity zurückschreiben.

Erschwerend kommt hier hinzu, dass zB eine 100GB-Datei in vielen kleinen Einzelwrites erstellt wird, das Trim aber bloss ein einziger Befehl sein kann, wenn die nicht fragmentiert war.

Daher nächstes Probem - die Operation muss in mehreren Tranchen abgearbeitet werden, weil der Cache nicht groß genug ist, die Parity-Stripes und die Datenstripes liegen ja abwechselnd auf je einer Platte. Damit wäre der Controller viele Sekunden lange beschäftigt, die doppelte Datenmenge einzulesen und die einfache Menge wieder zurückzuschreiben, und für den Rest ein Trim abzusetzen.
Bei RAID6 wäre das noch komplexer.

Dazu kommt noch, dass ein Controller kein Gedächnis hat, welche Datenstripes schon getrimmt sind, und müsste daher die Paritystripes ungetrimmt lassen. Oder er untersucht den Inhalt, wenn der nur aus 0x00en besteht, könnte er die trimmen. In logischer Konequenz könnte der Controller/die RAID-Software das gleich prinzipiell auch beim allen Schreibbefehlen veranstalten...

Zusätzliche Schwierigkeit ist, dass viele Controller oder Software-Lösungen die Platten bei Erstellung initialisierend beschreiben, und daher diese Bereiche vom Filesystem nie benutzt und nie belegt waren und daher auch nicht getrimmt werden.

 

[EspE]

ach du
ok, also wird das wohl nix. war ja nur ne idee,
hätt ja sein können das es funktioniert, lol.

soll ich den ersten beitrag bisl abändern und ein [xxx] im titel vorsetzen?
xxx? gelöst/warnung/beratung

 

[Holt]

Ich hab jetzt keine Ahnung, wie der TRIM-Befehl genau funktioniert - nehme aber ohne nachzusehen an, wird wie ein read oder write mit StartLBA, #LB den entsprechenden Bereich (eines im Filesystem gelöschten Datenbereiches) abgewickelt wird.

So ist es, es gibt einen StartLBA und #LB

Meine letzte Info war, dass TRIM nicht an RAID's funktioniert.
Wenn das inzwischen nachgereicht worden sein sollte, frage ich mich, wie das überhaupt bei einem RAID5 oder 6 funktionieren soll.

Ja, aber meines Wissens nur von Intel für Z77 und H77 (vielleicht noch mehr und bei Z68 geht es, wenn man das OROM des 77er da ins BIOS reinhackt) und nur für RAID 0!! Zu RAID 1 habe ich keine Aussage.

Bei RAID0 oder 1 kein Problem, aber wie sieht es bei RAID5 mit dem Parity-Stripe aus?

Das ist ein guter Punkt, nur schade dass die normalen RAID Controller es nicht einmal bei RAID 0 untersützen.

Nachdem ein Trim an die SSD abgesetzt wurde, ist der ursprüngliche Inhalt nicht mehr vorhanden. Liest man einen getrimmten Block, kriegt man 0x00en zurück.

I.d.R. geben die 00 zurück, aber das ist nicht definiert, die SSD darf da, genauso wie beim Lesen nicht auf Flashadressen gemappter LABs, also solcher die vorher nie beschrieben wurden, einfach irgendwas zurückgeben.

Daher müsste die RAID5 Logik den früheren Inhalt der zu trimmenden Einzelbereiche und der zugehörigen Parity erst einlesen, XORen und dann die neue Parity zurückschreiben.

Nicht den früheren Inhalt, den neuen, nach dem TRIM, nur ist das wieder schwer, denn wann die SSD das genau ausführt ist ebenfalls nicht genau definiert und dauer einige Sekunden bis Minuten. Solange ist der alten Inhalt da noch auslesbar. Und wie soll der RAID Controller es eigentlich bzgl. der Parity lösen, wenn da nun keine Nullen ausgelesen werden?
Eine sauberee Lösung wäre nur möglich, wenn der genauso wie der Controller der SSD Buch darüber führt, welche LBAs mit gültigen Daten beschrieben sind und welche nicht.

Erschwerend kommt hier hinzu, dass zB eine 100GB-Datei in vielen kleinen Einzelwrites erstellt wird, das Trim aber bloss ein einziger Befehl sein kann, wenn die nicht fragmentiert war.

Wo ist da ein Problem? Der Controller müsste die LBAs des TRIM Befehls natürlich auf die einzelnen Platten aufteilen und entsprechende neue TRIM Befehle für die einzelnen SSDs generieren, was er beim Lesen und Schreiben ja auch macht. Die Parity ist halt der springende Punkt.

Daher nächstes Probem - die Operation muss in mehreren Tranchen abgearbeitet werden, weil der Cache nicht groß genug ist, die Parity-Stripes und die Datenstripes liegen ja abwechselnd auf je einer Platte. Damit wäre der Controller viele Sekunden lange beschäftigt, die doppelte Datenmenge einzulesen und die einfache Menge wieder zurückzuschreiben, und für den Rest ein Trim abzusetzen.

Wieso er die alten Daten lesen sollte, verstehe ich nicht. Die neuen auch nur, wenn er die Parity hinterher entsprechend den zurücklesenen setzen will, sofern er eben nicht davon ausgeht, dass die sowieso 00 sind.

Dazu kommt noch, dass ein Controller kein Gedächnis hat, welche Datenstripes schon getrimmt sind, und müsste daher die Paritystripes ungetrimmt lassen. Oder er untersucht den Inhalt, wenn der nur aus 0x00en besteht, könnte er die trimmen.

Ist die Parity für 00 auch 00? Wenn ja, kann er die einfach trimmen und wenn nicht, dann würde die Parity nicht mehr stimmen und er würde Read-Errors melden, denn er weiß ja normalerweise nicht, ob die Daten nun gültig sein müssten oder nicht. Ist aber eigentlich bei einer neuen, unbeschriebene SSD nicht anders, oder beschreibt es grundsätzlich beim Einrichten des RAID alle LBAs um gültige Parities zu bekommen?

Zusätzliche Schwierigkeit ist, dass viele Controller oder Software-Lösungen die Platten bei Erstellung initialisierend beschreiben, und daher diese Bereiche vom Filesystem nie benutzt und nie belegt waren und daher auch nicht getrimmt werden.

Dann ist TRIM sowieso für den Eimer, denn damit ist die SSD für den SSD-Controller voller gültiger Daten.

Von einem RAID 5 oder 6 aus SSD kann man nur abraten. Wer es doch machen soll, der sollte einen guten Teil der Kapazität ungenutzt lassen, aber nicht nur für das Filesystem, auch für den RAID Controller, wenn der halte die Platten am Anfang initialisierend beschreibt! Sonst wird man immer nur einen recht kleinen Teil der Kapazität wirklich schnell beschreiben können.

Wie man SSDs für Einsätze ohne TRIM auswählt, habe ich hier erst vor kurzem erklärt. Wie man am Beispiel der m5 mit der FW 0001 im Vergleich zur FW 0009 sieht, kann sich das Verhalten aber mit jeder neuen FW Version auch wieder ändern.

 

[Ernst@at]

So ist es, es gibt einen StartLBA und #LB

Inzwischen nachgeblättert, das Command heißt "DATA SET MANAGEMENT", als Anzahl Sektoren(#LB) max. 65536 möglich, also 32MiB am Stück.

I.d.R. geben die 00 zurück, aber das ist nicht definiert, die SSD darf da, genauso wie beim Lesen nicht auf Flashadressen gemappter LABs, also solcher die vorher nie beschrieben wurden, einfach irgendwas zurückgeben.
Nicht den früheren Inhalt, den neuen, nach dem TRIM, nur ist das wieder schwer, denn wann die SSD das genau ausführt ist ebenfalls nicht genau definiert und dauer einige Sekunden bis Minuten. Solange ist der alten Inhalt da noch auslesbar.

Der "undefinierte Inhalt" wird wohl als Beschreibung gewählt sein, weil bis zur Durchführung der alte Inhalt, danach aber (als neuer Inhalt) 0x00en zurückgegeben wird. Was anderes als einer diese beiden Inhalte wäre technischer Schwachsinn.

Und wie soll der RAID Controller es eigentlich bzgl. der Parity lösen, wenn da nun keine Nullen ausgelesen werden?
Eine sauberee Lösung wäre nur möglich, wenn der genauso wie der Controller der SSD Buch darüber führt, welche LBAs mit gültigen Daten beschrieben sind und welche nicht.

Ginge auch anders, der RAID-Controller(Software) müsste vor dem TRIM einfach 0x00en reinschreiben und die dann Trimmen. Damit gibt es in jedem Fall des Lesens, egal ob das Trim schon ausgeführt ist oder nicht, definitiv 00en.

Wieso er die alten Daten lesen sollte, verstehe ich nicht. Die neuen auch nur, wenn er die Parity hinterher entsprechend den zurücklesenen setzen will, sofern er eben nicht davon ausgeht, dass die sowieso 00 sind.
...
Ist die Parity für 00 auch 00?

Der XOR-Zauberspruch lautet:
(1) a xor a = 0
(2) a xor 0 = a
(3) 0 xor 0 = 0
(4) a xor b = b xor a (die Position der Operanden ist egal)
(5) a xor b xor c = (a xor b) xor c = a xor (b xor c) = (a xor c) xor b (Die Reihenfolge der Operationen ist egal)
(6) a xor b = p; ==> a xor p = b; b xor p = a

Warum er die alten Daten lesen muss, hier ein Beispiel.
wir haben bei RAID5 und 5 Platten ein Stripeset mit 4 Datenstripes A B C D und einem Paritystripe

A B C D P

die Parity kann auch an anderer Position stehen, was aber keinen Einfluss hat.
in jedem der Datenstripes A B C D befindet sich je nach Stripesize eine definierte Anzahl an Sektoren.
ein beliebiger Sektor a aus A hat einen an gleichem Offset im Stripe befindlichen Partner b c d und p
für die gilt (wie auch für das gesamte Stripe)
a xor b xor c xor d = p

Wenn jetzt der Sektor a neuen Inhalt a1 durch Schreiben bekommt, muss
- entweder b,c,d gelesen werden, p neu ausgerechnet und a,p zurückgeschrieben
- oder eleganter das alte a und p gelesen, p1=p xor a xor a1; und a1, p1 zurückgeschrieben
werden.

Wenn ja, kann er die einfach trimmen und wenn nicht, dann würde die Parity nicht mehr stimmen und er würde Read-Errors melden, denn er weiß ja normalerweise nicht, ob die Daten nun gültig sein müssten oder nicht.

Würde statt den Sektor a zu beschreiben, dieser getrimmt werden, dann müsste der Controller
- das alte a und p lesen, p1 =p xor a; a1=0; und a1, p1 zurückschreiben
- dann a trimmen.
Damit bliebe die Konsistenz gewahrt.

Ist aber eigentlich bei einer neuen, unbeschriebene SSD nicht anders, oder beschreibt es grundsätzlich beim Einrichten des RAID alle LBAs um gültige Parities zu bekommen?

Das hängt vom Controller ab, üblicherweise werden nur die Paritystripes aus den Daten errechnet und neu geschrieben, damit der Array konsistent ist.
Die Frage ist natürlich, was anschließend bei einer Formatierung des Filesystemes passiert, wenn es ein Full-Format ist. Zuerst Nullen hinschreiben, um dann den großen unbenutzten Bereich zu trimmen, wäre bei Win komödienreif, aber denkbar.

Wenn ein RAID-Controller nach der obigen Methode arbeiten würde, wäre eine TRIM-Unterstützung bei RAID5 natürlich möglich, bis sowas aber implementiert wird, dauerts wohl noch.
Sinnvollerweise sollte der dann aber auch gleich alle Sektoren, bei denen nur 00en als Inhalt geschrieben wird, sofort trimmen, womit auch Parity-Sektoren frei würden

 

[Holt]

Der "undefinierte Inhalt" wird wohl als Beschreibung gewählt sein, weil bis zur Durchführung der alte Inhalt, danach aber (als neuer Inhalt) 0x00en zurückgegeben wird. Was anderes als einer diese beiden Inhalte wäre technischer Schwachsinn.

Schwachsinn oder nicht, wenn die Spezifikation die Freiheit lässt irgendwas zurückzugeben, dann macht es irgendwann auch mal jemand und dann müssen die anderen auch damit klar kommen.

Ginge auch anders, der RAID-Controller(Software) müsste vor dem TRIM einfach 0x00en reinschreiben und die dann Trimmen. Damit gibt es in jedem Fall des Lesens, egal ob das Trim schon ausgeführt ist oder nicht, definitiv 00en.

Das könnte er natürlich aber abgesehen von dem was oben steht, würde es ja wehtun, wenn man vor dem TRIM noch mal überschreibt. Das gäbe eine höhere Write Amplification und schlechtere Performance. Man stelle sich nur vor, in dem Moment schreibt auch der Rechner wieder auf diese Adressen...

Die Frage ist natürlich, was anschließend bei einer Formatierung des Filesystemes passiert, wenn es ein Full-Format ist. Zuerst Nullen hinschreiben, um dann den großen unbenutzten Bereich zu trimmen, wäre bei Win komödienreif, aber denkbar.

Genau das passiert aber, denn nach einem Format trimmt Windows eine SSD. Alles andere wäre auch unsinnig, denn sonst wäre die SSD für den Controller ja voller gültiger Daten und es könnten allenfalls die paar GB der Free Area schnell beschrieben werden. Unsinnig ist es eigentlich bei einer SSD ein Vollformat zu erlauben, aber meinte MS vielleicht, man könnte es den Usern nicht so einfach nehmen wie den Start Button.

Wenn ein RAID-Controller nach der obigen Methode arbeiten würde, wäre eine TRIM-Unterstützung bei RAID5 natürlich möglich, bis sowas aber implementiert wird, dauerts wohl noch.
Sinnvollerweise sollte der dann aber auch gleich alle Sektoren, bei denen nur 00en als Inhalt geschrieben wird, sofort trimmen, womit auch Parity-Sektoren frei würden

Solange alle nur 00 zurückgeben wenn ein getrimmter LBA gelesen wird, passt das, vorausgesetzt die SSD verarbeitet die TRIM Befehle bevor wieder lesend auf diese LBAs zugegriffen wird.

Wie man sieht, passen diese ganze RAID Techniken dann nicht zu SSDs, wenn die Parity ins Spiel kommt. Der RAID Controller weiß ebenso wie ein HDD Controller nicht, welche Bereiche nun wirklich gültige Daten enthalten und welche nicht, denn das ist bei einer HDD ja auch egal. Der SSD Controller weiß es zwar, aber der RAID Controller kann es nicht vom ihm erfahren. Am Besten wäre also eine Integration der RAID und SSD Controller Funktionen in einem Chip.

Andererseits: Wer braucht ein RAID 5 aus SSDs? Wenn man Performance will, dann ist ein RAID 0 besser, denn es dürfte nicht so viele RAID Controller geben, die mit der Parity Berechnung in der Geschwindigkeit mehrerer schneller SSDs nachkommen und dann wird ja auch mehr geschrieben. Eine echte Beschleunigung bringt ein RAID aus SSDs vor allem dort, wo SSD im Vergleich zu HDDs sowieso viel besser sind, also entweder bei den wirklich langen seq. Zugriffen oder bei sehr vielen parallelen Zugriffen.