Nitewing schrieb:
Du willst es nicht hören, aber ein SSD Raid0 ist wirklich Blödsinn. (Zugriffszeiten werden länger.)
Das hängt davon ab wo das RAID realisiert ist. Vor allem (ältere) SAS Controller mit Cache erhöhen die Zugriffszeiten von SSDs gewaltig, weil die eben noch auf die Zugriffszeiten von HDDs ausgelegt waren und daher deren Cacheverwaltung eben nicht so schnell sein musst.
Aber überlege mal, was bei einem Zugriff auf eine Datei so alles passiert bis der / die LBA(s) ermittelt sind, auf die zugegriffen werden muss. Wenn man den Cluster kennt, muss noch der Offset der Partition daraufgerechnet werden und dann wird anhand der Clustergröße der LBA ermittelt. Kenne Windows den Cluster aber nicht weil er nicht im Cache steht (unbelegtes RAM wird ja als Diskcache verwendet), so muss der erst aus den ganze Metadaten ermittelt werden, also im Extremfall vom Rootdirectory aus der ganze Pfad bis zur Datei jeweils einzeln eingelesen werden, was dann jedes mal die beschrieben Schritt und den Zugriff auf das Laufwerk beinhaltet. Ob da nun noch einmal von der CPU eine Umrechnung des LBAs auf die lokalen LBAs des RAIDs erfolgt, spielt bei einem i7 nun wirklich keine Rolle mehr. Softraids sind daher heute meist schneller als die klassischen RAID Controller, da deren Kerne einfach viel langsamer sind als aktuelle CPUs.
Nitewing schrieb:
Der Intel Controller unterstützt Trim, wenn EINE SSD und ein oder mehrere Arrays aus Festplatten im Raid laufen, ein Raid aus mehreren SSDs wird nicht mit trim unterstützt.
Diese Information ist veraltet! Mit dem passenden RAID ROM im BIOS und einem aktuellen Intel RAID Treiber können auch SSDs in einem RAID 0 getrimmt werden. Bei einem RAID mit Redundanz, also z.B. einem RAID 1 oder RAID 5, geht TRIM dagegen nicht. Das ist da auch nicht so leicht, dann sonst würde es beim Lesen getrimmter Bereich auch zu Inkonsistenzen kommen, weil bei einem RAID 5 z.B. die Parity dann auch alle 00 wären und bei einem RAID 1 würden die Daten nicht stimmen, wenn eine SSD die TRIM Befehle schneller umsetzt als die andere.
conspectumortis schrieb:
Trim geht anscheinend nur bei SSD Raid 0 arrays. Soweit bin ich schon, aber nicht weiter.
So ist es, aber eben nur, wenn die Voraussetzungen stimmen.
conspectumortis schrieb:
Zugriffszeiten sind glaub auch abhängig wie man die Stripesize einstellt, deswegen auch die Frage.
Auf die Zugriffszeiten hat das Strippingsize keinen Einfluss, das bestimmt nur, ab welcher Zugriffslänge die Daten verteilt werden. Bei 64k gehen eben 64k auf die eine, die nächsten 64k auf die andere Platte. Erfolgt ein Zugriff mit 128k Länge, so kann im besten Fall, wenn der Zugriff genau auf das Stripping allignt ist, dies in genau zwei 64k Zugriffe aufgeteilt werden und im schlechtesten Fall hat man halt drei Zugriffe wie z.B. 32k + 64k + 32k. Wenn dann der RAID Controller die beiden 32k Zugriffe auf die eine Platte wieder zu einem 64k Zugriffe vereint, dann erreicht man auch mit einem kleinen Strippingsize hohe seq. Transferraten, sonst eben nicht, weil ja keine Zugriffe erfolgen, sie länger als das Stripping sind und SSD schon recht lange Zugriffe brauchen um ihre maximal seq. Transferrate zu erreichen.
Der Beschleungungseffekt eines RAID 0 tritt eben aber auch erst auf, wenn die Zugriffe wirklich deutlich länger als das Stripping sind. Bei einem 64k Zugriff und einem Stripping von 64k wird im Extrem nur ein 64k Zugriff auf eine SSD erfolgen, normalerweise aber ein Zugriffe von irgendwas zwischen 4k und 60k auf die eine, und von 60k bis 4k auf die andere SSD und da die bei kurzen Zugriffen recht langsam sind, gewinnt man dann noch gar nichts.
Da die meisten Plattenzugriffe aber i.d.R. sehr kurz sind, gerade auch die von Windows auf seine Systemdateien, gewinnt man mit einem RAID 0 aus zwei SSDs in der Praxis nur so 10% gegenüber einer einzelnen SSD. Deshalb ist es eigentlich immer vorzuziehen sich eine große SSD statt zwei kleinere zu kaufen, zumal es meist günstiger ist, die größeren dann selbst oft noch schneller sind (ok, bis zu einer Grenze und s gibt Ausnahmen, so werden die mit einem Sandforce über 240GB dann wieder langsamer) und vor allem, weil man von den größeren länger gut hat, denn für eine 500GB SSD wird man auch dann noch eine sinnvolle Nutzung finden, wenn man schon nichts sinnvolles mehr mit einer 250GB anfangen kann, auch wenn das noch ein paar Jahre hin sein wird. Aber vor kurzem war oft noch die Frage, ob man besser zwei 64GB oder eine mit 128GB SSD kauft und schon heute sind 128GB alles andere als üppig, was fängt man dann mit einer 64GB SSD noch an?
conspectumortis schrieb:
deshalb die spezifische Frage nach den Samsung SSDs + Board.
Wenn TRIM funktioniert und das sollte es wenn der richtige Treiber drauf ist und die nicht uralte ROM im BIOS haben, dann passt das, von dn oberen Überlegungen zu zwei kleinen statt einer großen SSD mal abgesehen.
conspectumortis schrieb:
Natürlich kann man bestellen, testen und wieder zurückschicken. Aber das geht auf Kosten des Verkäufers, das ist auch nicht Sinn der Sache.
Gesunde Einstellung, denn am Ende zahlen doch immer wir Kunden die Zeche, was viele leider vergessen.
conspectumortis schrieb:
Das war meine größte Befürchtung, dass die Stripesize mir zuviel Kapazität wegnimmt.
Das Stippsize kostet keine Kapazität!
conspectumortis schrieb:
Eine Datei die nur 1Kb bspw. hat, wird bei mir bisher auf dem Datenträger mit 4 gespeichert und bei 64 > dachte ich mir, da windows und auch andere Programme viele kleine Dateien nutzen, dass da soviel weggeht..
Da verwechselst Du aber Clustersize (also die Größe der Zuordnungseinheiten des Filesystems) mit dem Strippingsize. Jede Daten belegt immer einen ganzen Cluster (ganz kleine werden bei NTFS in den Metadaten gespeichert, Ausnahmen bestätigen mal wieder die Regel), aber das hat mit dem Stripping nichts zu tun, das besagt nur, wie viele Daten maximal am Stück auf einer Platte stehen.
conspectumortis schrieb:
Bei mehreren Seiten habe ich gelesen, dass die 4k Performance wieder steigt und die Zugriffszeit wieder sinkt, wenn eine höhere Stripesize genutzt wird
Wie soll den die 4k Performance steigen? Allenfalls die IOPS, also z.B. 4k_64 oder 4k QD32 steigen, weil die viele parallelen Zugriffe sich ja dann auf zwei SSDs verteilen.
conspectumortis schrieb:
Außerdem würde ich gerne wissen ob die Bootzeit sich auch wieder normalisiert wenn die Stripesize optimal gewählt wird
Die Bootzeit hängt vor allem von der Zeit für die Initialisierung der HW ab und in diesem Fall kommt dann die für das Fake-RAID dazu, aber das hat mit dem Stripping nichts zu tun.
conspectumortis schrieb:
Zusätzlich war irgendwas mit dem write back cache. Manche meinten es bringe mehr wenn es bei einem Raid0 deaktiviert wird. Wie und Warum genau habe ich nicht herauslesen können.
Das verstehe ich auch nicht ganz, aber dem größeren Puffer des RAID Treiber zusammenhängen. Der muss ja mehr puffern, weil der die Daten beim Schreiben ja aufteilen und beim Lesen dann wieder zusammenfügen muss, bevor er sie weiterreicht. Aber das er das bei deaktivieren Schreibcache dann schneller macht, kann ich mir irgendwie nicht so recht vorstellen.