Vielen Dank euch beiden!
Ich probier's mit der ES.3, Größe ist kein Prob, wir haben jetzt 500GB, die neue ist 1TB. Wenn das doch nicht geht, guck ich mir den Kontroller an. Tät mir aber leid, wir verwenden 3Ware in verschiedenen Servern schon seit Jahrzehnten...
So, schon wieder ist der Besitzer gewechselt.
Was da wohl los ist? 
Die heissen nun Broadcom Limited Company.
3Ware -> Avago -> Broadcom
Edit:
Noch ne Frage: wie kommen denn die 9650er Controller mit SSD's zurecht?
Wäre das machbar bzw sinnvoll?
Schönen Tag Euch in diesem Sinne Leute 
Ackso ist das.
Muss aber sagen, dass mir weder Broadcom jetzt noch Avago bis zur damaligen Übernahme etwas sagten.
Ich meine dunkel in Erinnerung zu haben, dass es von Broadcom NICs gab. Lieg ich da richtig?
Ansonsten plane ich, meinem NAS ein letztes Mal upzugraden.
Der aktuelle 4000+ x2 kommt raus und ein Athlon II x4 615e rein.
Dazu ein zweiter 9650er Controller.
Daran sollen dann zwei 128GB Samsung 840 Pro fürs OS im Raid1 und am anderen Controller ebenfalls der 2lp mit den Storageplatten - auch im Raid 1.
Ah, da klingelt es schon eher!
Ich hatte kaum bis nie was (zumindest direkt) mit denen was zu tun. Aber beim Raspberry klingelts.
Mercie für die Info!
Habe mich zum letzten Treiber ein bisschen eingelesen. Dieser supportete die X25 Intel SSD's.
Eine solche würde ich heute selbst in den Server nicht mehr stecken, weil zu alt.
Denke aber auch, dass die 840er Pro arbeiten sollten.
Etwas großartiges wirds eh nimmer.
Werde schaun, was ich dann stromspartechnisch noch rausholen werden, damit ich ihn öfter lassen kann.
Wenn er noch 4 Jahre durchhält, hat der eh seine 10 Jahre auf dem Buckel.
Meine Güte, wie schnell die Zeit vergeht!!
Klingt vielleicht kindisch, aber mir kommts wie letzte Woche vor, als ich ihn gebaut hatte.
Da kommt man schon ins Grübeln, wenn man älter wird...
Ok, das ist aber ein anderes Thema. Jedenfalls sollte das Upgrade nochmal einiges an Geschwindigkeit rausholen.
Das wird dann etwas für den Winterurlaub. Da nehm ich mir dann mal nen Tag Zeit für den Server.
Immerhin werkelt er seit 2010 fehlerfrei. Und das auf nem Consumermainboard. 
( ASUS M4N78-AM )
Das erfüllt einem schon mit ein bisschen Stolz und Freude, weil die Daten (Fotos) sicher an einem anderen Platz sind. 
TRIM fehlt halt, also gilt Mal wieder: Unbedingt SSDs mit Garbage Collection kaufen!
Haben das nicht anyway alle SSDs ? Das gehört doch irgendwo zur Grundfunktionalität die überhaupt notwendig ist, damit die SSD nicht irgendwann komplett an unnötigen Pages verrottet.
Broadcom Netzwerk Chips... sind ja Praktisch auf jeden Mainboard der letzten jahre das mir durch die Hände ging egal ob Arbeit oder Privat.
Wobei TRIM und GC ja zwei unterschiedliche Paar Schuhe sind.
Ich kann mir kaum vorstellen, dass es SSDs gibt die in sich kein GC beherrschen. Das Feature muss ja per se auf der SSD selbst bzw. im Memory Controller integriert sein und nicht auf dem ATA Controller bzw. gar im OS. Wäre das nicht vorhanden, würde die Platte doch nach einiger Zeit immer mehr an Speicher verlieren und vermutlich derbe langsam werden 
Soweit ich das mal verstanden habe gehört das zu der grundlegenden Funktionalität einer jeden SSD, da ansonsten zig Blöcke un-wiederbeschreibbar verbleiben würden. Besonders beim Überschreiben von Daten (das ja so auf der Platte dann eben gar nicht stattfindet, sondern quasi ein Verschieben der noch gültigen Pages und löschen der alten Sektoren) wäre das irgendwann der absolute Tod
TRIM hilft ja dann eigentlich "nur" mit der konkretisierten Information, welches Pages gar nicht mehr genutzt werden und unterstützt damit GC bzw. verhindert so unnötiges rumkopieren von Blöcken, deren Inhalt gar keine Bedeutung mehr hat.
"Wäre das nicht vorhanden, würde die Platte doch nach einiger Zeit immer mehr an Speicher verlieren und vermutlich derbe langsam werden" - und genau das ist auch schon zig SSDs widerfahren, zumindest was die Leistung angeht, s.u. So z.B. meiner Intel G1, die ich im Einsatz habe, also pre-Postville...
GC als eine grundlegende Funktionalität? Dem ist nicht immer so - Stichwort Read-Modify-Write Zyklen. Es gibt also keine "un-wiederbeschreibbaren" Bereiche, es gibt nur Bereiche, die eines R-M-W Zyklus bedürfen. Auch eine SSD ohne GC und TRIM (von der es einige gibt, speziell bei den älteren Modellen) bleiben funktional, auch wenn alle Pages einmal beschrieben worden sind. Der I/O Scheduler und Dateisystemtreiber des Betriebssystems weisen einen Write an, der so nicht durchgehen kann, weil es keine freien SSD Blocks mehr gibt? - die Daten werden zuerst von der SSD gelesen (ein voller Block, meist 512kiB oder 1MiB groß), dann mit dem vom OS kommenden Write modifiziert, wonach der komplette gelesene und modifizierte Block wieder rausgeschrieben wird. Das führt zu einer erhöhten Write Amplification und einer deutlich niedrigeren Schreibleistung, sowohl sequentiell wie auch random.
Dennoch funktioniert eine SSD ohne GC genauso wie eine mit GC, nur eben schlechter, wenn sie nicht TRIMmed wird. Es gibt dann auch noch unterschiedlich gute/schlechte GC Implementierungen, wo auch bei Vorhandensein des Features starke Degenerationen stattfinden, sobald kein TRIM mehr zur Verfügung steht.
Die Samsung 840 Pro hat eine - laut Berichten - ausgesprochen gute GC Implementierung, bzw. der in ihr verbaute MDX Controller hat sie.
Aber: GC ist IMHO keine geeignete Lösung zur Standardisierung des SSD Betriebs, weil GC in seiner Qualität stark implementierungsabhängig ist. Eine SSD, die TRIM beherrscht, braucht auch keine Garbage Collection mehr, weil es schlicht keinen "Garbage" mehr gibt, den man rauswerfen müßte, sobald TRIM durchgelaufen ist... Und TRIM ist in seiner Natur nicht implementierungsabhängig, funktioniert also auf jeder SSD in der selben Qualität, solange keine Firmwarebugs vorliegen.
So zumindest meine Ansicht in der Thematik auf Basis meines aktuellen Wissensstands.
Mit "un-wiederbeschreibar" meinte ich eben genau Sektoren die zunächst einen Löschzyklus benötigen würden, bevor sie wieder nutzbar sind.
Das man solche Murkse wie von dir beschrieben wirklich macht und die SSD volllaufen lässt vermag doch zu erstaunen.
Das GC ganz klar von der Stärke der jeweiligen Implementation abhängig ist liegt in der Natur der Sache: Es ist bei weitem nicht schwarz auf weiss, sondern bedarf einer entsprechend intelligenten Strategie und deren Implementierung.
Was ich aber nicht verstehe ist, wieso GC mit TRIM überflüssig wird ? Reallocated TRIM per se Pages wenn die Sektoren entsprechend in sich bereinigt werden ?
Ich sah bisher TRIM nur als Unterstützung für GC an in Bezug darauf, keine unnötigen Pages rumzubugsieren.
Ich glaube wir sprechen vom gleichen 
Mit "Löschen" meine ich nicht die Nutzeraktion eine Datei zu löschen, sondern das effektive, physikalische Löschen und somit komplette wiederbereitstellen eines Sektors.
Soweit ich verstehe, ist das Schreiben auf Pages ja immer möglich solange diese leer sind (das, was ich als "gelöscht" bezeichne). Ich kann aber eine Page nicht überschreiben, ohne diese zuvor zu "löschen", dies geht aber nicht wie schreiben direkt auf der Page, sondern nur auf dem Sektor.
Also muss ich ja die Daten irgendwie mal so arrangieren, dass ich komplette Sektoren frei bekomme, was ja GC grundlegend tun soll. Ansonsten würden ja die Sektoren mit verwaisten Pages irgendwann die SSD füllen, ohne die effektive Kapazität je erreichen, bzw. wird die Fragmentierung pervers.
Ab dem Punkt käme ja dann die RMW Strategie zum tragen. Ich meinte nur immer, dass man sowas eigentlich gar nie macht bei einer SSD und bin daher davon ausgegangen, dass GC eine absolute, autonome Grundfunktion einer jeden SSD sein müsste.
Interessante Ausführung danke
(Dir ist es sicher klar, aber ich schreibs nur extra noch Mal her: Echtes physikalisches "Löschen" ist dasselbe wie "Überschreiben". Da besteht kein Unterschied. Man kann Daten nur entfernen, indem man sie überschreibt. Meistens geschieht das einfach durch's Wegnullen der Blöcke, weil am einfachsten.)
Jepp, das ist klar (ich vereinfache das meistens nur einfach ein wenig zu heftig...).
In der ganzen Sache scheine ich wohl tatsächlich die durchschnittlichen Writes zu überschätzen, meiner Meinung nach müsste eine SSD ohne GC recht schnell in die Wand rennen. Daher auch meine bisherige Annahme, GC sei ein eigentlich zwingendes, autonomes Feature, damit die Platte einigermassen fit bleibt.
Spannend an der Sache finde ich, dass GC vermutlich (habs nie richtig recherchiert) sehr aufwändig und eben trotzdem "schmutzig" ist (das Wort beschreibts perfekt).
