News Feldstudie: SLC-SSDs nicht zuverlässiger als MLC-Laufwerke

Wie schlecht die Administration bei Google funktioniert hat, sieht man doch anhand der Studie leicht selbst. Da stehen doch in Table 1 die Avg. PE cycles und die sind bei den MLC SSDs mit 730, 949, 529 und 544 sogar eher höher als bei den SLC und eMLC SSDs. Dabei wäre die Nutzung von denen bei den schreibintensiven Anwendungen zu erwarten und die der SSDs mit normalen MLC NANDs eher für die Leseintensiven Anwendungen. Dann sieht man in Figure 2 auch MLC SSDs die jenseits der angegebenen 3000 P/E Zyklen genutzt wurden, was in einer Enterprise Umgebung nicht der Fall sein sollte, mal abgesehen davon das die 3000 sowieso kein typsicher Wert für 43/50nm NANDs sind. Außerdem stammen bei denen 7 Modelle vom Vendor I, nur je eines von einem anderen Hersteller.

Wer ist dieser dominierende Hersteller? Am Ende vermutlich Google selbst:

Google tops the list of enterprise SSD sales
Google in an astonishing development was named as the world’s 4th largest SSD vendor in enterprise SSD sales survey report presented by Gartner. The reputed research firm lists the internet juggernaut at the 7th spot in the list of vendors with the largest revenues coming from SSDs through a market share of 8.9%. Till date Google was never known as a hardware vendor and with the latest disclosure of the research firm, all eyes have fallen on the big G as they are surprised that when did this company enter SSD market.

Although, Google is now listed among the top 10 overall SSD vendors when measured by revenue, it is hard to find someone who has bought a Google SSD drive till date. It is a known fact that Google’s storage architecture consists 45% of SSDs. Since, they are reliable, low power consuming and produce less heat; they are preferred by the search giant in most of its essential fast performance oriented application needs.

After creating a bit of media buzz with its latest report, Gartner clarified that Google is not actually selling SSDs to other companies. Conversely, it is obtaining SSDs and generating revenue by their internal use.

Google never disclosed the details of which SSD vendor it prefers in its storage architecture. But they are rumors that Google has acquired a small SSD manufacturer and is backing it up financially. Pretty soon, they are chances that Google might also announce to the world that it does have its presence in SSD business and may come up with its own Google SSDs brand in coming months.

As flash is key element in its storage architecture there is a rumor that Google might acquire Marvel controllers and Intel NAND and from then on entertain only these two brands in its data center infrastructure.

Zum Vergrößern anklicken....

Zumindest 43nm NAND gab es von Intel / Micron nie, sondern z.B. von Toshiba / SanDisk.

Holt schrieb:

Dann sieht man in Figure 2 auch MLC SSDs die jenseits der angegebenen 3000 P/E Zyklen genutzt wurden, was in einer Enterprise Umgebung nicht der Fall sein sollte, mal abgesehen davon das die 3000 sowieso kein typsicher Wert für 43/50nm NANDs sind.

Zum Vergrößern anklicken....

Google betreibt seine DCs nicht als Enterprise DCs. Die Dinger werden verwendet bis sie tot sind. Consumer-Hardware kein Problem. Macht jeder größere Hoster so, reduziert die Kosten massiv und dank weitreichender Replizierung kein Problem.

Holt schrieb:

Wer ist dieser dominierende Hersteller? Am Ende vermutlich Google selbst

Zum Vergrößern anklicken....

Wenn man nicht weiß was verwendet wurde dann kann man wie du nicht die Studie einfach so als falsch abtun. Deshalb sind deine vorherigen Kommentare reine Spekulation und Hater-Kommentare. Mehr nicht.

Da sollte man eher dem Reviews vertrauen, als irgendeinem aus dem Forum.

Viel Interessanter wären Auswertungen von MLC zu TLC SSD´s, da ich z.B. von TLC gar nichts halte und SLC als Privatperson kaum Bezahlbar und Kaufbar sind.

mfg

strex schrieb:

Wenn man nicht weiß was verwendet wurde dann kann man wie du nicht die Studie einfach so als falsch abtun.

Zum Vergrößern anklicken....

Was?
Das ist ja furchtbar naiv.
Natürlich kann man das. Man kann so einiges.
Sollte man das? Ja? Natürlich. Das nennt sich kritisches Denken. Das wird dir allerdings nur in "höheren" Schulen (Gymnasium) in der Oberstufe beigebracht.
Nein, das ist kein Scherz. Da gibt es extra eine Projektwoche für in NRW bei dem einem der jugendliche Leichtsinn ausgeredet wird mit manipulierten Graphen. Leider ist sowas exklusiv und die Einstellung nicht selbstverständlich in der Bevölkerung. Wie man an dir scheinbar auch sieht.

strex schrieb:

Wenn man nicht weiß was verwendet wurde dann kann man wie du nicht die Studie einfach so als falsch abtun.

Zum Vergrößern anklicken....

Was ich kritisiere, sollte wohl klar geworden und sehr wohl nachvollziehbar sein.

strex schrieb:

Deshalb sind deine vorherigen Kommentare reine Spekulation

Zum Vergrößern anklicken....

Spekulation ist was Du hier schreibt, z.B. über die Arbeitsweise bei Google und das die NAND minderer Qualität mit nur 3000 P/E Zyklen bekommen haben, in einer Zeit als solche NANDs normalerweise mit 10.000 P/E spezifiziert wurden und gute NANDs noch keineswegs knapp waren, im Gegenteil hatten Anbieter wie Micron damals sogar Probleme diese überhaupt auf dem Markt los zu werden.

strex schrieb:

Da sollte man eher dem Reviews vertrauen

Zum Vergrößern anklicken....

In bestimmten Aspekten stoßen Reviews an ihre Grenzen, da die eben nur eine Kurzzeitbetrachtung erlauben. Was man aber klar in fast jedem Review sehen kann ist, dass es sinnfrei ist eine SSDs getrennt vom Controller zu betrachten.

Der Controller ist ja für die Verwaltung des NANDs verantwortlich und wenn die Vorgaben z.B. zu den einzuhaltenden Timing und Spannungen beim Schreiben und Löschen nicht richtig eingehalten werden, dann kann NAND eben auch schneller altern und fehleranfälliger sein, da kann aber dann das NANDs nicht dafür und bei denen haben ja offenbar einige NANDs mehr fehlerhafte Blöcke bekommen als vom NAND spezifiziert wird. Da besteht schon der Verdacht, der Controller habe die Vorgaben eben nicht eingehalten, z.B. um mit mehr Performance glänzen zu können. Dann hat er die Fehlerkorrektur zu machen, damit die internen Fehler im NAND wie z.B. gekippte Bits eben nicht nach außen kommen und er hat Refreshes der NAND auszuführen, damit eben Read Disturb kein Thema ist, offenbar haben da ja auch einige der Controller der SSDs in der Studie versagt, wie in 4.3. am Beispiel der MLC-B SSDs zu sehen ist. Die hatten im beschleunigten Test keine unkorrigierbaren Fehler, aber im Praxiseinsatz schon, der Unterschied ist da vor allem die Zeit und damit eben Ladungsverluste und Read Disturb. Eine Ursache für Uncorrigierbare Fehler haben sie ja auch nicht gefunden, nur das die meisten NAND Fehler erst beim Lesen aufgefallen sind und da zeigt sich ein Versagen der verwendeten Controller.

20% bis 63% der SSD haben bei denen unkorrigierbare Fehler gezeigt, ich habe seit mehr als 5 Jahren zahlreiche SSDs im Einsatz und außer der plötzlich verstorbenen Vertex2 (anerkanntes Schrottmodell mit einem Controller der das Erstlingswerk aus einer Startupbude war) nie einen Fehler gesehen und einige haben wirklich eine Menge TBW runter. Auch in den S.M.A.R.T. Werten von den SSDs im Netz sind solche Fehler bei guten SSDs die Ausnahme, solange sich die NANDs nicht dem Lebensende nähren. Google hat wohl einfach Schrott SSDs weil sie Schrott Controller verwenden, eben offenbar von einer kleinen Firma die sie gekauft haben. Es tummelten sich viele Anbieter im Markt, aber nur wenige waren wirklich gut und die setzen sich durch und heute dominieren mit Intel und Samsung nicht zufällig zwei Großkonzerne mit eigener NAND und Controllertechnologie den Enterprise-SSD Markt.

SLC war nie das Über-NAND und SLC SSDs nicht die Wunder-SSD für das manche es immer noch halten. Man schau sich an wie die MTRON und die Intel X25-E im Dauerschreibtest auf xtremesystems.org abgeschnitten haben. Die MTRON waren auch schnell und unter komischen Umständen kaputt und die SLC NANDs der X25-E waren nicht besser als die MLC NANDs der X25-M. Die immer wieder genannten 100.000 P/E Zyklen für SLC halte ich für schamlos übertrieben. Bei der Intel X25-E 64GB hat sich jedenfalls nach 579.46 TiB der Available Reserved space von 100 auf 99 verringert, obwohl es angeblich keine Reallocations gab, S.M.A.R.T. Attribute sagen eben nicht immer die Wahrheit, nach 625.97 TiB sind dann die ersten beiden Reallocated sectors aufgetaucht, da waren gerade erst 5% der Spezifizierten Zyklen verbraucht. Bei 665.36 TiB waren es 7 Reallocated sectors, bei 702.41 TiB schon 27 und der Wert ist munter weiter gestiegen.

Im Vergleich dazu hat sich bei der Intel X25-M G1 80GB nach 431,9031 TiB die Anzahl der Reallocated sectors von 02 auf 04 erhöht (den Post 0 auf 2 habe ich nicht gefunden) und da war der MWI auf 82, es waren also nur 18% der Spezifizierten P/E Zyklen verbraucht. Bei 439,2336 TiB waren es 5 (MWI 80), bei 443 TiB 7 (MWI 79) und Ende war sie nach 883.46 TiB, da war der Zähler der Reallocated sectors schon mehrfach übergelaufen (ist der Aktuelle Wert, nicht der Rohwert) und auch der MWI war schon unter 0 und wieder bis 235 runter. Der Available Reserved space war auf 16 gefallen.

Beiden haben den gleichen Controller, beiden haben 80GiB NAND verbaut und auch wenn die Meldung über das Ableben der X25-E fehlt, so war bei der letzten Meldung nach 1.58 PiB der Available Reserved space von 25 (bei 1.49 PiB) auf 14 gefallen, die SSD also sehr nahe am Ende und hatte nicht einmal doppelt so viele Daten geschrieben, was schon alleine aufgrund der wegen der viel größere OP geringeren Write Ampliciation möglich sein könnte.

Vergleicht man das noch mit der Crucial m4 64GB, die genau darüber auch nahe dem Ende ist aber noch lebt und 2110.8663 TiB (=2.06PiB) geschrieben und 36477 P/E Zyklen überstanden hat, obwohl sie 20% weniger NAND und auch nur das MLC in 25nm statt in 50nm wie die beiden Intel hat, so zeigt das doch deutlich, dass SLC nicht so eine mythische Haltbarkeit hat und die Fortschritte der Controller sowie der NAND Fertigung die prinzipiellen Nachteile von mehr Bits pro Zelle und kleineren Fertigungsstrukturen durchaus mehr als ausgleichen können.

Was man aus der Studie mitnehmen kann ist meiner Meinung nach vielleicht nur die Erkenntnis, dass man besser SSDs von den großen, renommierten Anbieter statt solcher von kleinen Bastelbuden kaufen sollte.

SSDs unzuverlässiger als HDD-Laufwerke... und teurer.

"In puncto Fehlerraten seien SSDs aber im Nachteil. Innerhalb des Testzeitraums hätten über 20 Prozent der Flash-Laufwerke nicht korrigierbare Fehler aufgewiesen. Bei 30 bis 80 Prozent seien fehlerhafte Blöcke (bad blocks) und bei 2 bis 7 Prozent fehlerhafte Speicherchips (bad chips) aufgetreten. Bei HDDs seien wiederum laut Berichten nur 3,5 Prozent von fehlerhaften Sektoren betroffen, was zudem in Relation zur erheblich höheren Anzahl an Sektoren gegenüber Blöcken und Chips von SSDs zu betrachten sei. Demnach müssen SSDs zwar seltener als HDDs ausgetauscht werden, jedoch geht dies mit höheren Fehlerraten einher."

Das deckt sich mit meinen Erfahrungen. Es nützt mir wenig, wenn ein Datenträger noch rein formal funktioniert, meine Daten oder mein OS aber zerstört sind. Bei Google ist das nicht so wichtig.

Feldstudie:
https://de.wikipedia.org/wiki/Feldstudie

feris schrieb:

Aber was hat das mit einem Backup zu tun?
Daten ohne Backup sind per Definition unwichtig.
...
Was auch vernachlässigt wird:
Für mich als Privatman ist es schon ein Unterschied, ob ich einen Fehler oder einen Brick bekomme.
Mit dem ersten kann ich leben, mit dem zweiten schon schlechter.
Daher wäre das eher interessant: Was wird eher zum Brick? SSD oder HDD?

Zum Vergrößern anklicken....

Was nützt mir ein Backup, wenn das System nicht bemerkt, dass ein Teil der Daten defekt ist? Bis ich das bemerke, sind ältere, intakte Backups vielleicht überschieben. Mir ist ein "ehrlicher" Datenträgerverlust lieber als schleichende Datenzerstörung. Den Datenträgerverlust muss der Hersteller vielleicht in den ersten 5 Jahren ersetzen, was mir reicht. Bei Datenverlust grinst der mir frech in's Gesicht.

Bei unkorrigierbaren Fehler geben SSDs und HDDs einen Lesefehler aus, die geben keine korrupten Daten zurück, aber natürlich muss die SW diese Fehler auch korrekt verarbeiten, sie darf also nicht so tun als wäre nichts passiert und dann eine Datei unvollständig einlesen. Unbemerkte Datenkorruption hat ihre Ursache also so gut wie nie im Datenträger selbst, bei Heimanwendern sind RAM Fehler die Hauptursache. Wer kein ECC RAM und natürlich ein entsprechendes restliches System hat, der darf über Silent-Data-Corruption sowieso nicht erst nachdenken, denn er fährt da volles Risiko mit einem System welches für solche Fehler offen wie ein Scheunentor ist. Erst wer diese Scheunentor geschlossen hat, der kann dann auch z.B. Überlegungen in Richtung der Internal-Data-Path-Protection seiner Laufwerke anstellen, da gibt es nämlich auch Unterschiede und wenn die internen Datenpfade nicht vor Bitfehlern geschützt sind, dann kann es schon mal passieren, dass ein Laufwerk wirklich falsche Daten liefert, aber das ist vergleichsweise selten der Fall.

Einige HDDs z.B. von Seagate haben immerhin eine Erkennung die man an dem Ende-zu-Ende Fehler Attribut in den S.M.A.R.T. Werten erkennen kann, da ist es bei den viele S.M.A.R.T. Werte die ich hier und in anderen Foren gesehen haben, schon sehr selten das es dort mal Probleme gibt. Einige Consumer SSDs haben sogar einen Schutz der internen Datenpfade, z.B. die von Crucial mit Marvell Controllern.

Bussard schrieb:

Was nützt mir ein Backup, wenn das System nicht bemerkt, dass ein Teil der Daten defekt ist?

Zum Vergrößern anklicken....

Tja, gute Frage, die ich mir bei jedem Backup auch immer wieder aufs Neue stelle...
Der erste Teil des Satzes ist klar (Backup: gegen Datenträger-Totalausfall), aber wie löst man den zweiten Teil?
Fakt ist, dass - frei nach Nena - irgendwie, irgendwann und irgendwo gewisse Merkwürdigkeiten im System auftreten, deren ihre Ursache hier zu finden wäre?

Interessehalber: Wie sorgen z.B. Linux-Kernel-Entwickler dafür, dass - bei Millionen von weltweit abgespeicherten und durch tausende von über den Globus verstreuten Einzelentwicklern vorgenommene Änderungen - alle Datensätze 100,0% auf den einzelnen Servern synchronisiert bleiben?

Nachtrag:

Holt schrieb:

Wer kein ECC RAM und natürlich ein entsprechendes restliches System hat, der darf über Silent-Data-Corruption sowieso nicht erst nachdenken, denn er fährt da volles Risiko mit einem System welches für solche Fehler offen wie ein Scheunentor ist.

Zum Vergrößern anklicken....

Auch das. Früher hatte ich immer darauf bestanden, AMD-Desk-Tops mit (öfters mal überprüften) ECC-RAM zu bestücken, aber mit aktuellen Intel-bestückten Lap-Tops geht das ja wohl nicht (mehr)...

Mit den mobilen Xeon E3-1500M v5 kommt ja nun endliche eine passende Plattform für mobile Workstations, nur kosten die entsprechenden Notebooks richtig viel Geld, ab 3000€ geht es los. Dabei kostet der E3-1505M v5 mit 434$, ein i/-6700HQ ist mit 378$ ist so viel günstiger und 200MHz langsamer, aber Notebooks mit dem gibt es ab unter 1000€, wenn auch natürlich mit schlechterer Ausstattung.

Auch der E3 1535M v5 kostet mit 623$ nicht so wahnsinnig viel mehr als der i7 6920HQ für 568$ mit praktisch identischen Spezifikationen, also etwas über 10% Aufpreis. Aber wenn man ECC RAM fähige HW haben will, muss man meist sehr tief in die Taschen greifen. Das ein C236er Chipsatz mit 49$ gerade mal 2 USD mehr kostet als ein Z170 für 47$, glaubt man kaum wenn man sich die Preise der entsprechenden Boards ansieht und der C236 bietet mit 8 SATA Ports ja sogar auch zwei mehr als der Z170.

Bussard,

ich glaube das Fazit hast Du falsch verstanden. Insgesamt betrachtet sind SSDs zuverlässiger, als HDDs.

Nachtrag: Die Studie hat zu teils kontroversen Diskussionen geführt. Es bleibt festzuhalten, dass die Erkenntnisse lediglich für den Workload in Googles Rechenzentren mit vergleichsweise niedrigem Schreibaufkommen gelten. Die Studie sagt nichts über die generelle Haltbarkeit (endurance) von SLC- oder MLC-Speicher aus. Vielmehr zeigt sie, dass es für Google keine Vorteile bedeutet, SLC-SSDs zu nutzen. Bei sehr hohem täglichen Schreibvolumen würden SLC-SSDs sehr wahrscheinlich ihren Vorteil durch eine höhere Haltbarkeit ausspielen.

Mr.Seymour Buds schrieb:

. Insgesamt betrachtet ...

Zum Vergrößern anklicken....

... ist ein dehnbarer Begriff. Langfristig betrachtet... sind wir alle tot.

Wenn beim Klonen oder bei der Neuinstallation ein einziges Bit auf der SSD kippt, dann kann das später zu unerklärlichen BSOD führen. Ich schätze mal 10% der BSOD sind mindestens Bitfehler. Windows bringt eben KEINE Meldung bei Bitfehler an den Benutzer - oder kann mir jemand entsprechende Fehlermeldungen zeigen. Windows kann nie kontrollieren, ob ein Klonvorgang oder eine Installation erfolgreich war.

Hashing a hard drive before shutdown ... oder offline
http://security.stackexchange.com/questions/72439/hashing-a-hard-drive-before-shutdown

Bevor ich dann 3 Stunden suche, den PC wieder auf schraube, Ersatz beschaffe, defekte SSD einschicke... gebe ich lieber gleich 50 oder 100 Euro mehr aus für eine hoffentlich zuverlässigere SSD. Unzuverlässig bedeutet nicht Totalausfall sondern ständigen Ärger.

http://extreme.pcgameshardware.de/n...s-nicht-zuverlaessiger-als-mlc-modelle-2.html
"schon blöd wenn du statt plus plötzlich minus auf dem Konto hast"

Und ich bin überzeugt, in dem Punkt Bitfehler ist SLC am zuverlässigsten.

Bei Google wäre es nicht so schlimm, wenn jemand nach CVJM sucht und in einem Sexshop landet.

Es kippen normalerweise keine Bits auf SSDs, im NAND passiert das bei heutigen NANDs mehr oder weniger laufend, aber die ECC wurde auch gewaltig weiter entwickelt und verhindert, dass dies nach außen hin bemerkbar wird. Das geht ja auch aus der Studie hervor, die konnten keine Verbindung zwischen der RAW Bit Error Rate und den unkorrigierbaren Fehlern feststellen. Wenn also auf dem Klonen ein Bit anderes als auf dem Original ist, hat sehr wahrscheinlich das RAM des Rechners dieses zu verantworten und die RAM Fahler kann man nur mit ECC RAM verhindern (meist nur die Singlebit Fehler) oder eben erkennen, sonst erkennt man sie nur an ihren Folgen wie eben Bluescreens oder korrupte Dateien. HDDs und SSDs liefern eben Fehlermeldungen, aber praktisch nie verfälschte Daten, außer das Bit ist auf den ungeschützten internen Datenpfaden gekippt. Bei der SATA Übertragung gibt es pro FIS, also maximal 8192Byte Nutzdaten, eine CRC32 und das reicht um mit einer Wahrscheinlichkeit von etwa so 1:10^40 jeden Übertragungsfehler zu erkennen und außerdem sollte man in den S.M.A.R.T. Werte sowieso erkennen, wenn es Fehler bei der Übertragung gibt und dann reagieren, also das SATA Kabel prüfen und ggf. ersetzen, denn durch die ständigen Wiederholungen laggt sonst meist der ganze Rechner.

Also nochmal: Wer sich um Bitfehler Gedanken macht, der sollte zu aller erst einmal ECC RAM und ein passendes System nehmen, ob SLC, MLC oder TLC in der SSD steckt, spielt dagegen keine Rolle, die interne ECC die der Controller der SSD verwaltet, kompensiert die Bitfehler des NANDs und wenn nicht, taugt der Controller nichts, aber selbst dann sollte er eben mit einer Fehlermeldung antworten und wird keine falschen Daten liefern. Alles andere ist ein Bug.

Holt schrieb:

... sollte ...

Zum Vergrößern anklicken....

In welcher Form kommt bei Windows diese Meldung? Wie lautet der Fehletext? Es könnte ja sein, dass ich das bisher mehrmals übersehen habe. Wieso arbeitet Windows damit einfach weiter ohne, dass man dafür ausdrücklich mit OK bestätigen muss. Acronis streikt dann, das weiß ich.

"Inerhalb des Testzeitraums hätten über 20 Prozent der Flash-Laufwerke nicht korrigierbare Fehler aufgewiesen." Bei jeder 5. SSD trat das im Testzeitraum (4 oder 5Jahre) mindesten 1 Mal auf. Google verwendet bestimmt nicht das allerbilligste Material und deren Server sollten bestimmt ECC Ram haben, wobei wir hier nicht beim Thema Ram sind.

Das sind auch meine Erfahrungen.

Im Explorer bekommt man beim Kopieren den E/A Fehler, was andere Programme dann machen, hängt vom jeweiligen Programm ab. Wenn es den Fehler ignoriert und die halb gelesene Datei einfach als geladen betrachtet, dann ist aber nicht die Platte sondern das Programm schuld. Beim Klonen gibt es meist auch Abbrüche und Fehlermeldungen, weshalb man ja auch Platten mit schwebenden Sektoren mit dem Linux Tool ddrescue klonen sollte, dann bekommt man wenigstens die noch lesbaren Sektoren geklont. Das der Inhalt des Klons dann vom Original abweicht, sollte auch klar sein, solche Klons nimmt man auch nur zur Datenrettung und auch nur, wenn man beim Backup geschlampt hat.

Die Probleme die Google mit den SSDs hatte, dürften den Controllern der SSDs geschuldet sein, die wurden aber nicht genannt. Welche es sein könnten ist schwer zu sagen, die 480GB deuten spontan auf Sandforce hin, aber die Sandforce kamen erst später auf den Markt, nicht zu den Zeiten als noch 43nm / 50nm NAND üblich war und dann wären sie auch nicht in der Lage gewesen mit die NANDs, die ja noch eine kleine Diesize hatten, so große SSDs zu realisieren, ebensowenig wie andere Consumer SSD Controller aus der Zeit dazu in der Lage gewesen wären. Das dürften also spezielle Enterprise Controller gewesen sein, die Aussagen über die S.M.A.R.T. Werte in der Studie deuten auch in diese Richtung.

Die Controller dürfte auch klar die Fehlerursache gewesen sein, weshalb eben auch kein Zusammenhang zwischen den NANDs und den Fehler feststellbar war. Der Controller ist eben immer noch das wichtigste Bauteil einer SSD und wenn man da Schrottcontroller nimmt, bekommt man Schrott-SSDs, da ist gutes NAND nur Perlen vor die Säue geworfen und schlechte Controller gab es gerade früher sehr viele.