Nur 16 Bit: Einige HPE SAS SSDs fallen nach 32.768 Stunden aus

[HWL News Bot]

Via Support-Mitteilung veröffentlicht HPE ein kritisches Firmware-Update für einige seiner SAS-SSDs, da eine Betriebsdauer von mehr als 32.768 Stunden dazu führen kann, dass sämtliche auf dem Laufwerk befindliche Daten komplett verloren gehen. Grund dafür ist ein Zähler in der Firmware, der über eine Länge von 16 Bit verfügt. Gezählt werden hier die Betriebsstunden. 216 ergeben 65.536 Stellen, da auch in den negativen Zahlenbereich gezählt werden kann, bleiben 32.768 Stunden übrig, die als Betriebsstunden gezählt werden können. Dieses Maximum von 3 Jahren, 270 Tagen und 8 Stunden haben einige der Laufwerke nun offenbar erreicht."Neglecting to update to SSD Firmware Version HPD8...

... weiterlesen

 

[geist4711]

boah is sowas peinlich!
da sind dann evtl existenziell wichtige kundendaten futsch, weil ein fauler programmier-heinzel
es nicht für nötig hielt den zähler 32bit laufen, bzw zählen, zu lassen mit so einem ergebnis.
wenn der zähler dann wenisgtens bei 0 wieder anfangen würde,
aber nee, die ca. eine zeile mehr programmcode hat man sich auch gespart!

sicherheitsdenken? fehlanzeige!
nachdenken beim programmieren was das für folgen hat?
egal, mein smartphone wechsel ich auch nach 2 jahren, also geht der zähler eh nie bis zum ende
weil man schon was neues hat......

wie in firmenumgebungen wird hardware gerne so lange wie sie läuft verwendet
und nicht deuernd durch den neusten hype ersetz?

uuups!?............

 

[VorauseilenderGehorsam]

Ach, mein schöner Jahr 2000 Problem Kommentar ist weg

 

[P4LL3R]

Ich muss zustimmen, das ist ein ziemlich peinlicher Fehler. Aber Kundendaten sollten nicht "futsch" sein, da es von wichtigen Daten immer mindestens ein Backup geben sollte, alles andere ist grob fahrlässig. Und ich kenne kaum jemanden, der im Backup-System SSDs hat. Ein paar als Cache, ja, aber nur SSDs? Eher nicht.

 

[pete81]

Komisch... ein Betriebsstundenzähler der bei erreichen seiner Maximalzahl die Daten löscht...
Ich denke da eher an geplante Obsoleszenz, nur hat sich einer beim Zähler-Maximalwert verschrieben...
Schnelle Google Suche: Die Teile haben anscheinend (meistens) 3 Jahre Garantie zumindest einzeln gekauft.
Wäre sehr auffällig wenn im Server z.B. 8 von den Platten sitzen und alle verabschieden sich kurz nacheinander (oder gleichzeitig)...
Da könnte man ja locker Betr*ug nachweisen...

 

[Don]

Ach, mein schöner Jahr 2000 Problem Kommentar ist weg

Das war auch ein 16 Bit Problem

 

[GenFox]

Terabytegroße Speicher und dann kein Platz für ein paar mehr Zeichen

 

[taeddyyy]

Da haben die ihre geplante Obsoleszenz wohl falsch programmiert.
Sollte bestimmt heißen defekt nach 32.768 Stunden +- 3000 Stunden

 

[DeckStein]

Ich bin mir sicher dass die pressemitteilung juristisch 0 wert hat.

 

[passat3233]

Das war auch ein 16 Bit Problem

Das betraf aber fast ausschließlich Pentium-Systeme.
In der Firma hatten wir noch ein paar 486er und ich habe noch meinen Nostalgie-286er und 486er.
Keiner dieser Rechner hatte das Jahr 2000 Problem.
Das hatten damals in meiner Firma nur diverse Pentium 90/100/120.

 

[smalM]

Das war auch ein 16 Bit Problem

Nein, das Jahr-2000-Problem war die zweistellige dezimale Speicherung der Jahreszahl.
Hier hingegen handelt es sich schlicht um ein falsch gewähltes Integer-Datenformat.
Entweder war irgend ein Jungspund sich nicht bewußt, daß "int" eben nicht immer und überall 32bit bedeutet, sondern auf manchen Systemen dafür "long" gewählt werden muß, oder es hat jemand vergessen "unsigned" zu wählen.
Ich tippe auf ersteres...

 

[Don]

Nein, es geht darum warum ein Post nicht mehr da ist – sollte ein Witz sein. Die 16 Bit bezogen sich nicht auf das Jahr-2000-Problem.

 

[VorauseilenderGehorsam]

Ich hab dich schon verstanden

 

[smalM]

@Don
Daß es ein Scherz sein sollte ist mir schon klar, der Bezug fehlte nur - hat er doch erst 3493 Posts!

 

[Rollo3647]

Dieser Zähler ist ja nicht einfach ein Prozessorregister das hochgezählt wird, würde bei stromausfall verloren gehen.
Also Flash Speicherzellen: jede stunde ein Byte incrementieren, bei Übertrag höherwertiges Byte incrementieren u.s.w.
Evtl. hat der Programmierer nicht bedachte das das 3te Byte noch eine andere Funktion hat.

 

[Shevchen]

"Wenn der Kunde zu faul ist, die Firmware unserer Premium-Produkte, die als sicher klassifiziert worden waren und tausend Award Zertifikate draufgeklebt haben zu aktualisieren..."

Fehler können immer mal passieren - auch bei Firmware. Die Art und Weise wie HP aber drauf reagiert, würde mich als Kunden dazu veranlassen zu sagen: Na ja, bei so ner unfreundlichen Art kauf ich halt nicht mehr bei dir ein. Gibt genug andere, bei denen ich meine Serverprodukte beziehen kann."

Die Arroganz von HP ist ja schon fast auf CISCO Niveau. Haben die etwa T-Systems aufgekauft, oder woher kommt das?

 

[Holt]

Ich denke da eher an geplante Obsoleszenz, nur hat sich einer beim Zähler-Maximalwert verschrieben...
Schnelle Google Suche: Die Teile haben anscheinend (meistens) 3 Jahre Garantie zumindest einzeln gekauft.

Einzel gekauft dürfte die Ausnahme sein, die kommen ja meist in den Komplettsystemen und Server laufen i.d.R. 5 Jahre, mit einem ebenfalls 5 Jahre laufenden Wartungsvertrag und im Dauerbetrieb, von daher ist dies klar ein Bug und sonst nichts.

Entweder war irgend ein Jungspund sich nicht bewußt, daß "int" eben nicht immer und überall 32bit bedeutet, sondern auf manchen Systemen dafür "long" gewählt werden muß

Denke ich auch, denn mit unsigned wäre dann nach 7 Jahren auch Schluss. Es ist nun einmal eine große Anfängerfalle bei C und C++, dass die Breite der Datentypen eben vom System abhängt. Gute C Programmierer sind aber eben leider selten geworden.

 

[Don]

Intel kann so etwas offenbar auch: http://qdms.intel.com/dm/i.aspx/1B9BD88E-FE1A-49F4-841E-D12F6E6FEF53/PCN116772-00.pdf

March 2019, Firmware Revision XCV10110, Resolved 1.92TB and 3.84TB SKUs may become unresponsive at 1700 hrs. of cumulative Idle Power On Hours.

 

[DragonTear]

Denke ich auch, denn mit unsigned wäre dann nach 7 Jahren auch Schluss. Es ist nun einmal eine große Anfängerfalle bei C und C++, dass die Breite der Datentypen eben vom System abhängt. Gute C Programmierer sind aber eben leider selten geworden.

Was daran liegt dass man sich diese Sprache nur antut wenn man gezwungen ist, sobald man andere "höhere" Sprachen kennt.
Schlage mich zur Zeit selbst damit herum...

 

[Holt]

Intel kann so etwas offenbar auch

"1700 hrs. of cumulative Idle Power On Hours", also 1700 Stunden ohne einen Zugriff, wobei meiste schon das Auslesen der S.M.A.R.T. Werte, z.B. zur Überwachung der Temperatur, als Zugriff genügt um den Idle Zustand zu unterbrechen, sind nun schon echte selten. Sowas passiert allenfalls bei Hot-Spare Laufwerken, aber über 32.768 Betriebsstunden sollte für eine Server SSD normal sein, denn Server laufen meist im Dauerbetrieb und werden in aller Regel für eine Nutzungsdauer von 5 Jahren ausgelegt, gekauft und genutzt.

 

[underclocker2k4]

oder es hat jemand vergessen "unsigned" zu wählen.
Ich tippe auf ersteres...

Ich tippe auf beides.
Die Frage ist, warum jemand überhaupt einen signed Datentyp für einen Wert wählt, der 1. nur größer werden kann und 2. auch nicht aus dem negativen kommt, da die Betriebsstunden natürgemäß bei 0 anfangen.
Das ist ein klarer Fall von "ich brauche mal ne Ganzzahl -> go for Int" und nicht weiter darüber nachdenkt, wie sich das Datum entwickelt und was ich damit eigentlich anstelle.
Und weiterhin kann man sich dann noch Gedanken machen, was man mit dem Datum anfängt. Das Teil scheint ja nicht ganz unwesentlich an der internen Datenverarbeitung beteiligt zu sein...

 

[genzo]

Sowas passiert bei Integer bzw. ganz allgemein bei Datentypen einfach schnell. Häufiger Wechsel zwischen verschiedenen Sprachen, unterschiedliche Compiler, zu wenig Kaffee etc.
Der ursprüngliche Programmierer ist jetzt natürlich der größte Depp und hat sich vermutlich schon einen neuen Namen zugelegt, kann aber eigentlich wenig dafür.

Wir reden hier von einem Milliarden-Konzern und einem Enterprise-Produkt. Da erwarte ich eigentlich, dass eine Firmware mehrere Audits durchläuft, bis sie auch nur in die nähe eines echten Produkts kommt. Über diesen Code schauen unzählige Augen, oder sollten es zumindest, damit genau so etwas niemals passieren kann...

Und selbst wenn. Bevor ich so ein Produkt auf meine Kunden loslasse, stelle ich mir doch diverse Testsysteme für verschiedene Szenarien hin, damit ich bei solchen Ausfällen nicht kalt erwischt werde. Das sollte intern bei HPE schon vor Wochen, oder eher Monaten aufgefallen/ausgefallen sein.

Erinnert mich ein bisschen an die Crucial m2 aus meinem alten Rechner im Büro. Die hatte ein ähnliches Problem. Man konnte aber weiterin drauf zugreifen (wenn auch immer nur eine Stunde) um Daten zu sichern und nach einem Firmware-Update war das Problem komplett ohne Datenverlust behoben.

Was mich nur jetzt noch etwas verwundert ist, warum die Daten nicht wiederherstellbar sein sollen, bzw. auch ein Firmware-Update nach eintreten des Fehlers nicht mehr funktionieren soll.

 

[DragonTear]

Und selbst wenn. Bevor ich so ein Produkt auf meine Kunden loslasse, stelle ich mir doch diverse Testsysteme für verschiedene Szenarien hin, damit ich bei solchen Ausfällen nicht kalt erwischt werde. Das sollte intern bei HPE schon vor Wochen, oder eher Monaten aufgefallen/ausgefallen sein.

Naja, sowas in der Art hatten sie schon, denn ein Update welches das Problem fixt wurde schon lange bereit gestellt!
Manche Nutzer haben aber nicht geupdatet. Eventuell mit der Idee "never change a running System" :/ Oft kein so schlechter Rat, aber kann auch mal nach Hinten los gehen...

 

[genzo]

Das ist alles ein wenig undurchsichtig.

Wenn ich nach HPD8 suche bekomme ich tatsächlich eine Firmware vom Oktober 2016 angezeigt. Im Versionsprotokoll taucht das beschriebene Problem aber nicht auf.

Ich hab mir dann mal kurz das aktueller Customer Bulletin angesehen. Da findet sich eine Liste mit den Modellnummern betroffener Geräte inkl. eines Firmware Fix Date von letzten Freitag.

Es gibt sogar Modelle, für die ein Fix erst für die zweite Dezemberwoche angekündigt ist, mit dem dazugehörigen Hinweis, dass dort die Ausfallbedingung vorher gar nicht eintreten kann - wohl weil die Modelle erst zu einem späteren Zeitpunkt auf den Markt gekommen sind.

 

[Falo999]

Es ist auf jeden fall ein extrem böser und kritischer Fehler.
Wenn hier wer von geplante Obsoleszenz zuegt das nur das er keine Ahnung hat um was für Produkte es sich hier handelt.
Diese SSD laufen sicherlich zu 90% unter einen laufenen Service vertrag (Carepack) und wenn HP die Produkte ausmußern will wird einfach der Supportverttrag für diese Produkte nicht mehr verlängert.

Datensicherung ist zwar schön und gut das Problem ist ja in diesen Fall das praktische Gleichzeitige Ausfall des Produktes und das dann auch noch in den bei vielen Kunden beide Serverracks betroffen sind.

Im höchst sicherheitsbereich werden die Server meist von mehren Herrsteller und aus unterschiedliche Chargen gekauft.

Aber die normalen Firmen kaufen alle X Jahre die kompletten Server neu , die die es gut meinen haben 2 Serverstandorte die in unterschiedlichen Firmengebäuden stehen und dort dann Redundant gespiegelt aufgebaut werden.
Und da kommen halt alle SSD auf faktisch die gleichen Betriebsstunden.

Auf den SSD laufen halt in der Regel die VM's und Datenbanken während bei den meisten Firmen auch heute der Großteil der Daten auf Festplatten liegen.
Und diese VM's und Datenbanken wiederherrzustellen braucht man in der Regel auch ordentlich Zeit und in der Zeit können viele Firmen ihren Laden zumachen weil halt keiner mehr ohne EDV was ausliefern kann.


Fies ist auch das das updaten der HDD's und SSD oft etwas vernachlässigt wird , denn der Bug ja auch wirklich erst mit der Firmware vom 22.11.19 gefixt ist.

 

[Holt]

Bevor ich so ein Produkt auf meine Kunden loslasse, stelle ich mir doch diverse Testsysteme für verschiedene Szenarien hin, damit ich bei solchen Ausfällen nicht kalt erwischt werde.

Es ist aber nicht möglich damit einen Fehler zu finden der erst nach über 3 Jahren auftritt, denn so lange kann man gar nicht testen, da das Produkt sonst total veraltet wäre, bevor es auf den Markt kommen könnten und z.B. die NANDs so gar nicht mehr gefertigt werden, wie sie verbaut sind. Eine 100%ig Testabdeckung ist bei derart komplexen Systemen wie sie in der IT üblich sind, einfach nicht realistisch erreichbar.

Das sollte intern bei HPE schon vor Wochen, oder eher Monaten aufgefallen/ausgefallen sein.

Aber auch nur wenn sie selbst so ein System von vor dem Release bis jetzt ununterbrochen im Betrieb haben, aber entweder wurde das interne System schon lange durch den Nachfolger ersetzt, die sitzen ja an der Quelle und müssen daher keine so alten Rechner mehr einsetzen wie sie eben jetzt sind, wenn der Fehler auftritt oder sie wechseln auch nur alle 5 Jahre die Server und dann wäre es Zufall, wenn gerade ein Wechsel anstand, bevor die erste Systemen an Kunden gingen.

Erinnert mich ein bisschen an die Crucial m2 aus meinem alten Rechner im Büro. Die hatte ein ähnliches Problem. Man konnte aber weiterin drauf zugreifen (wenn auch immer nur eine Stunde) um Daten zu sichern und nach einem Firmware-Update war das Problem komplett ohne Datenverlust behoben.

Du meinst die Crucial m4, eine m2 gab es nie, der Vorgänger der m4 was die C300 und deren 5400h Bug.

Was mich nur jetzt noch etwas verwundert ist, warum die Daten nicht wiederherstellbar sein sollen, bzw. auch ein Firmware-Update nach eintreten des Fehlers nicht mehr funktionieren soll.

Offenbar hängt sich der Controller durch den Bug komplett auf, daher kommt man dann nicht mehr an die Daten.

 

[DragonTear]

Okey, ich dachte das Update sei älter.. Ja, das ist richtig doof gelaufen.
Ein paar exemplare zumindest seit einigen Wochen vor dem offiziellen Launch, schon in Betrieb zu nehmen wäre schon nicht zu viel verlangt. Dann hätte man den Kunden 2-3 mal so viel Zeit zum Updaten geben können.