News HPE SAS SSD: Update gegen Datenverlust bei 32.768 Betriebsstunden

[neuhier08]

Die wichtigsten Fragen sind für mich nicht beantwortet:

• Wer ist der Hersteller
• wieso passiert das
• Wer hat das wie festgestellt?

 

[Hallo32]

Die wichtigsten Fragen sind für mich nicht beantwortet:

• Wer ist der Hersteller
• wieso passiert das
• Wer hat das wie festgestellt?

Die Informationen gibt die Quelle nicht her.

 

[Zergra]

Ist glaube ich damals niemanden aufgefallen, weil man seine Crucial sowieso alle 14 Tage in der RMA hatte.

Nö, die laufen heute noch. In meiner Familie sind davon zwei seit 2010/2011 im Einsatz und zwar genau die m4 mit dem Bug. Hatte die 5200h aber nicht erreicht bevor das Update kam. Mittlerweile hat die eher 20 000h und mehr.

 

[Piktogramm]

• Wer ist der Hersteller
• wieso passiert das
• Wer hat das wie festgestellt?

Hersteller -> Unbekannt

wieso -> Das ist ein Integeroverflow eines 16bit signed Integers. Da hat jemand mit den Datentypen gepennt. Auch ein 16bit unsigned Integer wäre doof, schöner wären mindestens 32bit Integer als Betriebsstundenzähler

wer -> Irgendjemand, der die SSDs seit Markstart bzw. kurz vorher in Dauerbetrieb hatte.

 

[SaschaHa]

Das erinnert mich hart an den Mars Climate Orbiter, der auf die Oberfläche des Mars gekracht ist, weil man vergessen hat, die Zahlenwerte der Flugdaten vom amerikanischen ins metrische System zu konvertieren, wodurch insbesondere die Höhendaten von der Software falsch ausgewertet wurden

Manchmal frage ich mich echt, ob in den Software-Abteilungen mancher Firmen nur Chimpansen sitzen, die die Software ungetestet in den Markt entlassen.

Gar nicht auszumalen, was dieser Fehler für einen Schaden anrichten kann, wenn ein Unternehmen all seine Daten auf einem Cluster solcher SSDs speichert.

 

[snaxilian]

Dafür hat man ja Backups
Oft geung sitzen die Chimpansen nicht an der Tastatur sondern weiter oben in der Hierarchie. Entwicklung soll schnell gehen, darf nix kosten, etc. und am Ende hat man Bananenware, die kann beim Runden reifen da man ja Updates nachspielen kann.

 

[SaschaHa]

@snaxilian
Ein großes Problem hat man jedoch, wenn die Backups auf SSDs vom gleichen Typ liegen, was ja nicht unwahrscheinlich ist, da ja bei Serverfarmen oft identische Hardware gekauft wird, um Inkompatibilitäten zu vermeiden.
Ich kann für Betroffene nur hoffen, dass die Backups auf anderen Speichern liegen. Und ja, bezüglich der Hierarchie hast du absolut recht. Oft wird einfach an den falschen Ecken gespart.

 

[Holt]

Man kann sowas bestimmt auch als Beweis anführen, dass Hersteller mit sowas experimentieren, also geplante Opzoleszenz.

So ein Quatsch.

Erinnert sich noch jemand an den 5400-Stunden-Bug?
https://www.storagereview.com/node/2676

Eben, solche Fehler passieren, leider.

32.768*2 = 65536 (2^16) bzw. entspricht die Stundenzahl 2^15

Zufallszahl? Eher nicht. xD

Das ist der höchste positive Wert für ein 16 Bit Integer, also mit Vorzeichen und kein Zufall, aber des steht doch in der News "Der Zahlenwert 32768 entspricht 2^15". Das höchste Bit ist für negative Zahlen.

Ist glaube ich damals niemanden aufgefallen, weil man seine Crucial sowieso alle 14 Tage in der RMA hatte.

Wieso? Das bei den OCZ SSD vielleicht der Fall, aber die Crucial SSDs waren immer sehr zuverlässig. Keine Ahnung wie Du auf den Mist kommst.

Geplante Obsoleszenz 2.0

Sollte man in Grund und Boden verklagen so was..

Den Bogen sollte man um Leute machen die so einen Quatsch schrieben und sie wegen übler Nachrede und Geschäftsschädigung verklagen!

 

[andr_gin]

Das es absichtlich passiert ist, das ist natürlich Schwachsinn aber bei Serverkomponenten darf so ein Fehler nicht passieren vor allem weil es dann ja alle Datenträger im RAID Verbund gleichzeitig erwischt.

 

[BelneaHP]

Wir sind betroffen - einen ESX mit RAID 5 hats innerhalb von wenigen sekunden alle Platten restlos weggehauen - wir haben schon gedacht wir spinnen aber wo ich das nun lese ist alles klar.

 

[Apocalypse]

Vielleicht hat Steffen ja wirklich eine Idee, wie man das generell anders machen könnte. Die Zeitstempel von den Posts "hacken", ist es aber sicher nicht.

Schade eigentlich, weil dann wär es ja einfach.
Man könnte aber natürlich auch die Posts zuerst nach "News Startbeitrag" und "normaler Beitrag" sortieren und erst danach nach Zeitstempel. Muss man aber wahrscheinlich auch an die Innereien des Systems ran, aber es wäre kein Hack. ;-)

 

[Gangwars]

Dafür hat man ja Backups

Wäre nicht ungewöhnlich, wenn als Backup ein identisches System verwendet wird, oder zumindest identische SSDs, die zur gleichen Zeit im Betrieb genommen wurden. Also ... in anderen Worten ... You know you're in trouble when the fecal matter hits the rotary impeller.

Man kann sowas bestimmt auch als Beweis anführen, dass Hersteller mit sowas experimentieren, also geplante Opzoleszenz.

Da wurde nichts experimentiert. Du hast beim entwickelt Datentypen mit Wertgrenzen, ein Flüchtigkeitsfehler der Entwickler, der bei Tests und Qualitätssicherung nicht aufgefallen ist. Mal davon abgesehen wäre das auch unsinn ... Bei einer derart kurzen Laufzeit im Enterprise-Segment halte ich den Schaden, der dadurch verursacht wird, für deutlich höher als die Erlöse für Neuanschaffungen.
Da wurde nichts experimentiert.

-

Ich muss dann wohl schauen, ob einer unserer Server davon betroffen ist. Eine dadurch verursachte Downtime wäre äußerst ungeil.

 

[Mickey Cohen]

wieso -> Das ist ein Integeroverflow eines 16bit signed Integers. Da hat jemand mit den Datentypen gepennt. Auch ein 16bit unsigned Integer wäre doof, schöner wären mindestens 32bit Integer als Betriebsstundenzähler

das eigentliche problem ist doch, warum gehn die daten verloren, bloß weil der betriebsstundenzähler mist ausgibt? diese abhängigkeit dürfte schon garnicht existieren.

 

[mkossmann]

Intel verteilt seit März Firmwareupdates für einen ähnlichen Bug: https://www.thomas-krenn.com/de/wiki/Intel_D3-S4510_SSDs_und_D3-S4610_SSDs_Firmware_Update_XCV10110

 

[ImpactBlue]

Ich hab mich auch gleich an meine Crucial m4 erinnert gefühlt (die übrigens heute immernoch tut und nie zur RMA musste) aber wie Holt schon sagt:
Sowas passiert, leider.

Löblich finde ich immerhin, dass hierfür ein Update existiert und man damit das Problem beheben kann - naja vorausgesetzt das Update zerschießt einem nicht die Daten. Aber dafür gibt es wieder Backups. Theoretisch.

 

[Benj]

Ist glaube ich damals niemanden aufgefallen, weil man seine Crucial sowieso alle 14 Tage in der RMA hatte.

@snaxilian
Ein großes Problem hat man jedoch, wenn die Backups auf SSDs vom gleichen Typ liegen, was ja nicht unwahrscheinlich ist, da ja bei Serverfarmen oft identische Hardware gekauft wird, um Inkompatibilitäten zu vermeiden.

Das wäre dann aber streng genommen kein Backup. Spätestens aus dieser Geschichte sollte man das wieder lernen.

Wir sind betroffen - einen ESX mit RAID 5 hats innerhalb von wenigen sekunden alle Platten restlos weggehauen - wir haben schon gedacht wir spinnen aber wo ich das nun lese ist alles klar.

 

[Ledeker]

Das klingt nach Lebenszeitbegrenzung und erinnert an "Mysteriöser" Fehler bei HP-Druckern war bewusstes Ablaufdatum: https://winfuture.de/news,94063.html

 

[Chattermark()]

Wieso? Das bei den OCZ SSD vielleicht der Fall, aber die Crucial SSDs waren immer sehr zuverlässig. Keine Ahnung wie Du auf den Mist kommst.

Einige von uns waren selbst betroffen (Hallo, hier). Das hat mit übler Nachrede nichts zu tun.

Aber mit dem Rest hast du Recht, das kann halt passieren. Da gabs Ersatzgeräte und gut ist. Außerdem hatten andere Hersteller die Technik damals noch viel weniger im Griff, und den Support erst recht nicht. Ich denk da an meine erste SSD (Hersteller vergessen), die hatte alle paar Stunden Bluescreens produziert - das Firmware-Update das "bald" kommen sollte gibts bis heute nicht.

 

[DocWindows]

Manchmal frage ich mich echt, ob in den Software-Abteilungen mancher Firmen nur Chimpansen sitzen, die die Software ungetestet in den Markt entlassen.

Manchmal frage ich mich echt, ob sich die Genies dieser Generation hier im Forum versammeln, oder ob es Leute sind die wenig Ahnung haben aber gern schlau daherreden.

Wüsstest du so spontan einen Test mit dem du genau diesen Fehler beim Testing erkannt hättest? Welcher Test wäre das gewesen und was hättest du dir von diesem Test erhofft? Testparcours werden schließlich nicht ausgewürfelt, sondern entwickelt. Und jeder Test wird aus einem bestimmten Grund gemacht um ein bestimmtes potenzielles Fehlverhalten auszuschließen.

Dann kommt noch ein weiterer Faktor dazu: Zeit!
Wusstest du z.B. dass es für Firmen durchaus Sinn machen kann bei bestimmten Verträgen bewußt defekte oder mangelhafte Ware auszuliefern? Das ist immer dann der Fall wenn eine vertraglich vereinbarte Konventionalstrafe für Nichtlieferung den Wert einer Rücknahme und Neulieferung (mit neuen Terminen) übersteigt.

warum gehn die daten verloren, bloß weil der betriebsstundenzähler mist ausgibt? diese abhängigkeit dürfte schon garnicht existieren.

Das ist sicherlich keine Abhängigkeit in dem Sinne. Wenn der Zähler überläuft dürfte sich die positive Zahl der Betriebsstunden in eine negative Zahl umkehren. Wenn die Firmware das beim Starten und/oder Aktualisieren nicht abfängt, stürzt sie ab und bootet auch nicht mehr. Da man für Betriebsstunden selten negative Werte erwartet, weil Zeitreisen noch nicht funktionieren, fängt man das wahrscheinlich auch nicht ab.

Beim Thema Datenverlust bin ich mir nicht sicher wie das gemeint ist. Datenrettungsdienste werden die sicherlich wiederherstellen können. Der unmittelbare Zugriff ist aber nicht mehr möglich. Ein Controllerwechsel auf der SSD-Platine ist auch nicht jedermanns Sache, und wenn der Controller intern irgendwelche Datenzuordnungen in den eigentlichen Speicherchips vorhält, dann nützt dieser dir auch nichts. Hardwarebasierte Verschlüsselung habe ich auch noch gar nicht mit einbezogen.

Richtig schlimm könnte es werden, wenn man statt signed integer einen unsigned integer verwendet hätte, und somit das letzte Bit der integers auch noch für die Zahlenrepräsentation verwendet hätte.
Wenn der überläuft, wird die Zahl nicht Stundenzahl nicht negativ. Der höhere Wert schwappt dann möglicherweise quasi in den nächsten Speicherbereich über und überschreibt etwas anderes, möglicherweise wichtiges.

 

[Popey900]

einen ESX mit RAID 5 hats innerhalb von wenigen sekunden alle Platten restlos weggehauen

Ach du Sch....!
Wie erklärt man sowas einen Kunden ?