News Seagate FireCuda 120: SATA-SSDs mit bis zu 4 TB für die Spielesammlung

[foofoobar]

Was mir bei einer SSD noch wichtig ist, ist ein Notstrom-Kondensator, damit bei plötzlichem Stromausfall noch ein paar Daten geschrieben werden können.

Solange die Daten nicht persistiert sind darf fsync() nicht zurückkommen.

 

[boarder-winterman]

Ich warte auch noch auf günstigere 4TB SSD Preise, das Sterben der HDDs in meinem NAS geht mir auf die Nüsse...
Ich habe mittlerweile nur noch Seagate Enterprise Capacity HDDs verbaut, u.a. wegen der 5 jährigen Garantie, aber dennoch stirbt mindestens eine Platte pro Jahr.
Daher hoffe ich sehr darauf endlich günstigere SSDs kaufen zu können, 860 QVOs würden für den Zweck im NAS vollkommen reichen.

 

[DKK007]

Ist bloß die Frage ob die SSDs dann länger halt. Die Wahrscheinlochkeit für Bitfehler ist zumindest bei MLC-SSDs etwa 10mal so hoch. Bei QLC kannst du von Faktor 100 ausgehen.

 

[Popey900]

2,5 Zoll ist jetzt auch nicht mehr so taufrisch. ATX als Board Maße ebenfalls.... Also das Argument halte ICH für schwach. Zumal es ja logisch ist, das man auf 3,5 Zoll mehr Platz hat auf 2,5 oder gar bei M.2.

Das Argument ist sehr stark.
Weil
a) Hast du das Foto nicht gesehen ? 2,5" ist gerade zu einem Drittel belegt.
b) Hat 3,5" nur noch bei HDD's einen kleinen Vorteil.

 

[Nagilum99]

3,5 Zoll SSD

Also das nennt ihr "Verfügbar" ? Zum einen wenn es 2-3 Hersteller gibt, die in 3,5 Zoll immer mehr reinpacken wird der Preis auch sinken.
Aber 20-30TB als SSD und als Massenspeicher wäre mir einiges wert. Bei der Größe brauch ich auch erstmal keine Gen4 Werte. 1500Mb + würde vollkommen reichen. Davon 4 Stück und man könnte die Workstation ruhig laufen lassen.

Also 15 bis >30, wurde ja schon gepostet, gibt es bereits: https://geizhals.de/?cat=hdssd&xf=252_15360
Wenn du wirklich so breitwillig bist, auch viel Geld zu bezahlen: Hapert es jetzt echt an einem 2,5 auf 3,5" Adapter für 10 €?

 

[P4ge]

Das Argument ist sehr stark.
Weil
a) Hast du das Foto nicht gesehen ? 2,5" ist gerade zu einem Drittel belegt.

Wenn das bei allen/vielen 2,5 Zoll SSD´s so wäre ok. Dann nehme ich gerne mein Argument zurück. Die Bilder die ich aber zu hauf hier bei CB sehe, zeigen ein anderes Bild.

b) Hat 3,5" nur noch bei HDD's einen kleinen Vorteil.

Jaaaa und das bedeutet was? 2,5 Zoll bedeutet, dass an den Stellen X Y Z die entsprechenden Bohrungen/ Halterung im System sind. Gleiches gilt für 3,5 Zoll. Nochmals 3,5 Zoll hat physisch schon mehr Platz. Selbst wenn 2,5 Zoll nicht voll genutzt wird, hat 3,5 weiterhin noch mehr Platz.

Also 15 bis >30, wurde ja schon gepostet, gibt es bereits: https://geizhals.de/?cat=hdssd&xf=252_15360

Ja es hapert am Adapter. Warum muss ich Micron 9300 PRO als 2,5 Zoll kaufen und einen Halterahmen für 3,5 Zoll nur um die Festplatte ins Rack zu bringen. Warum kann es nicht gleich eine 3,5 Zoll Alternative geben. Bei 16 TB kann ich mir auch 2 x 8TB kaufen, klar. Aber ab einem gewissen Punkt geht das nicht mehr.
Wie gesagt, dass ist nur mein Wunsch als Konsument. Und diese Gruppe (3,5 Zoll SSD) an Konsumenten ist sehr sehr klein. Trotzdem würde ich mich drüber freuen. Mehr sage ich ja nicht.

 

[foofoobar]

Warum muss ich Micron 9300 PRO als 2,5 Zoll kaufen und einen Halterahmen für 3,5 Zoll nur um die Festplatte ins Rack zu bringen.

 

[Nagilum99]

Warum kann es nicht gleich eine 3,5 Zoll Alternative geben.

Weil das ein Nischenprodukt ist. Fast niemand hat Interesse daran Platz im Server zu verschwenden.
Warum sollte einer Server-/Storagesysteme für 3,5" Storage kaufen, wenn es das gleiche auch in 2,5" gibt?
3,5" kauft man nur noch, weil die gewünschten Datenträger dort günstiger zu haben sind: IdR. überschaubare IOPs und große Datenmengen.

Für '3' Kunden baut keiner neue Produktlinien auf.

Nochmals 3,5 Zoll hat physisch schon mehr Platz. Selbst wenn 2,5 Zoll nicht voll genutzt wird, hat 3,5 weiterhin noch mehr Platz.

Das interessiert doch quasi niemanden. Die 2,5" Backplanes haben dafür viel mehr Slots. Wer noch mehr will muss halt (künftig) die Ruler-Formate kaufen oder zu speziellenren Systemen greifen (z.B. HPE Apollo 4200).

 

[Popey900]

Jaaaa und das bedeutet was?

Vergiss es, dann warte auf deine 3,5" SSD's.

 

[Holt]

Solange die Daten nicht persistiert sind darf fsync() nicht zurückkommen.

Doch, wenn die SSD ein Full-Power-loss Protection hat und auch bei einem unerwarteten Spannungsabfall die Userdaten aus dem Schreibcache noch in die NANDs schreiben kann, dann darf sie ein fsync auch sofort quittieren, die nennt man sync faking und die HW RAID Controller mit BBU machen dies auch so. Leider halten sich nicht alle SSD daran, so haben z.B. die alte Sandforce Controller die sync gefakt, auch wenn sie keine Stützkondensatoren hatten.

Da die Hardware RAID Controller den Schreibcache der Laufwerke oft deaktivieren, macht übrigens einen deutlichen Unterschied bei der Performance bei Betrieb an HW RAID Controllern aus und man sollte daher immer Enterprise SSD für sowas einsetzen oder sollte sich nicht wundern, wenn die (Schreib-)Performance unerwartet schlecht ausfällt.

 

[Nagilum99]

Da die Hardware RAID Controller den Schreibcache der Laufwerke oft deaktivieren, macht übrigens einen deutlichen Unterschied bei der Performance bei Betrieb an HW RAID Controllern aus und man sollte daher immer Enterprise SSD für sowas einsetzen oder sollte sich nicht wundern, wenn die (Schreib-)Performance unerwartet schlecht ausfällt.

Das ist jetzt nur ein Bruchteil der Wahrheit: Die ROC schaffen nicht die XOR-Leistung, die nötig wäre um viele SSDs in einem RAID5/6 zu bündeln. Der Schreibcache ist dabei nicht das Problem. Außerden erhöht sich prinzipiell die Latenz. Allerdings meldet der RAID-Controller (also richtige, mit Cache und BBU/FBWC...) die Daten sofort als geschrieben, was u.U. besser sein kann. Am Ende hilft für das gewünschte Szenario nur: Try'n'Error.
Ein Kollege hat festgestellt, dass die alten HPE SmartArray x20/x30 z.B. bei rund 6 SSDs limitieren - er hat deswegen 4 verbaut. Die aktuelle Generation soll deutlich besser laufen. Er hat sich übrigens gegen Fastpath und für den Controller-Cache entschieden. Die Lösung war in Summe wohl günstiger als "enterprise" SSDs gegen Gold aufzuwiegen.

 

[foofoobar]

Doch, wenn die SSD ein Full-Power-loss Protection hat und auch bei einem unerwarteten Spannungsabfall die Userdaten aus dem Schreibcache noch in die NANDs schreiben kann, dann darf sie ein fsync auch sofort quittieren, die nennt man sync faking und die HW RAID Controller mit BBU machen dies auch so. Leider halten sich nicht alle SSD daran, so haben z.B. die alte Sandforce Controller die sync gefakt, auch wenn sie keine Stützkondensatoren hatten.

Da die Hardware RAID Controller den Schreibcache der Laufwerke oft deaktivieren, macht übrigens einen deutlichen Unterschied bei der Performance bei Betrieb an HW RAID Controllern aus und man sollte daher immer Enterprise SSD für sowas einsetzen oder sollte sich nicht wundern, wenn die (Schreib-)Performance unerwartet schlecht ausfällt.

Wie das Blockdevice die Persistenz herstellt ist nicht definiert. Und bei einem RAID interessiert die Persistenz des RAID Device und nicht der einzelnen Platten. Da helfen HW-Raid gerne mit Akkus und RAM nach, was völlig legal ist, allerdings darf dann der Kontroller mit dem Akku und RAM nicht kaputt gehen.

Ergänzung (31. Mai 2020)

Ein Kollege hat festgestellt, dass die alten HPE SmartArray x20/x30 z.B. bei rund 6 SSDs limitieren - er hat deswegen 4 verbaut. Die aktuelle Generation soll deutlich besser laufen. Er hat sich übrigens gegen Fastpath und für den Controller-Cache entschieden. Die Lösung war in Summe wohl günstiger als "enterprise" SSDs gegen Gold aufzuwiegen.

Zum Glück haben wir ein SAN mit SVC bei uns in der Firma so das ich mich nicht um sowas kümmern muss.

 

[Holt]

Wie das Blockdevice die Persistenz herstellt ist nicht definiert.

Richtig, wobei dies sowieso nicht gesetzlich geregelt ist.

Und bei einem RAID interessiert die Persistenz des RAID Device und nicht der einzelnen Platten.

Ein RAID ist ja aus Sicht des Controller auch ein Volumen dessen Inhalt konsistent sein muss. Aber die Frage ist doch, wie der RAID Controller das macht. Er hat seinen gepufferten DRAM Cache dessen Inhalt erhalten bleibt, sollte es plötzlich einen Spannungsabfall geben, aber dazu muss er beim Schreiben wissen, was wirklich auf der Platten geschrieben wurde, damit er es aus seinem eigenen DRAM Cache entfernen kann. Er "deaktiviert" also den Schreibcache der Platten, z.B. indem er hinter jedem Schreibbefehl ein fsync schickt, dies soll die Platte ja erst beantworten wenn die Daten persistent geschrieben sind.

Deaktiviere aber mal bei einer Consumer SSD den Schreibcache in Windows und benche sie mit dem AS-SSD Benchmark, wenn sie kein sync-Faking macht, dann brechen die Schreibraten, vor allem bei 4k, massiv von teils über 100MB/s auf wenige MB/s ein, denn die NAND Pages haben i.d.R. 16kB und müssen auf einmal beschrieben werden, wenn nun nur 4k im internen SRAM Schreibcache des Controllers stehen und er muss diese ins NAND schreiben, dann ist das saulahm und erhöht die WA gewaltig, denn normalerweise wird er damit warten bis genug Daten im Schreibcache stehen um eine ganze Page schreiben zu können. Hat die SSD aber selbst eine Full-power-loss protection (oder schummelt einfach, wie die Sandforce), dann beantwortet sie ein fsync sofort, durch die eigenen Stützkondensatoren kann sie die Daten aus ihrem Schreibcache ja immer noch in die NANDs schreiben, die Daten in ihrem Schreibcache sind also persistent wie die im DRAM Cache des RAID Controllers. Aber so eine Full-power-loss protection haben nur ordentliche Enterprise SSD, die Consumer SSDs wie z.B. die Crucial M500 bis MX300 haben nur Client Lösung mit Kondensatoren mit geringer Kapazität, nur genug für die data-at-rest, wie z.B. die letzten Änderungen Mappingtabelle (was aber bei denen auch nicht immer geklappt hat).

Bei so einer SSD mit Full-power-loss protection sieht man bei Deaktiviertem Schreibcache auch keinen Performnaceunterschied, da die ihren Schreibcache gar nicht deaktiviert und jedes fsync sofort beantwortet, auch wenn die Daten noch gar nicht im NAND stehen, aber dies ist ja in Ordnung, sofern die Kondensatoren wirklich vorhanden und die Daten damit geschützt sind. Die bringen dann an solchen Hardware RAID Controllern auch die volle Performance, aber die normalen Consumer SSDs werden saulahm, sofern man dem RAID Controller nicht abgewöhnen kann die Schreibcaches der SSDs zu deaktivieren, was dann aber bei einem unerwarteten Spannungsabfall das Risiko von Datenverlust in deren Schreibcaches bedeutet und daher geht es i.d.R. nur, wenn der RAID Controller eben keinen eigenen, mit BBU abgesicherten DRAM Cache hat. Dies ist ja auch konsequent, denn wenn der RAID Controller selbst Persistenz verspricht, er quittiert ja ein fsync vom Host sofort, wenn die Daten in einem DRAM Cache stehen und dieser per BBU gesichert ist, dann kann er ja nicht zulassen, dass sie womöglich im Schreibcache der Platte verloren gehen, nachdem die Platte selbst ihm das fsync quittiert und damit selbst die Persistenz der Daten bestätigt hat.

allerdings darf dann der Kontroller mit dem Akku und RAM nicht kaputt gehen.

Das ist klar, aber zumindest den Zustand des Akkus überwachen die Controller normalerweise ja.