Flere SSD-modeller fejler efter nøjagtig 32.768 timer

29. november 2019 kl. 14:2317
Flere SSD-modeller fejler efter nøjagtig 32.768 timer
Illustration: HPE.
Firmwareopdatering løser problemet, men skal installeres i tide.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Denne Samsung-producerede SSD fra HP Enterprise, med produktnummeret VO1920JFDGV, er blandt de berørte 20 modeller.

Lagringsenheder, som fejler efter nøjagtig 32.768 timers driftstid (2^15 timer), det lyder lidt specielt, men det er netop det, Hewlett Packard Enterprise (HPE) nu advarer kunderne om vil ske med en række SSD’er, hvis kunderne ikke opdaterer enhedernes firmware.

Det er en underleverandør af HPE, som har produceret SSD’erne, og det er denne leverandør, som har advaret HPE om problemet. I hvert fald én af SSD-modellerne, den som ses øverst i artiklen, er produceret af Samsung.

32.768 timer er det samme som 3 år, 270 dage og 8 timer.

Avancerede produkter

De berørte enheder tilhører en serie med SAS SSD’er, som er brugt i en række server- og lagringsprodukter fra HPE. Dette inkluderer produkter som ProLiant, Synergy, Apollo, JBOD D3xxx, JBOD D6xxx JBOD D8xxx, MSA, StoreVirtual 4335 og StoreVirtual 3200.

Artiklen fortsætter efter annoncen

I alt drejer det sig om 20 forskellige SSD-modeller. Detaljer om dem kan læses her.

Problemerne kan løses ved at opdatere firmwaren i de berørte enheder til version HPD8 eller nyere. Denne opdatering er nu tilgængelig for knap halvdelen af de berørte enheder. En opdatering til de resterende bliver gjort tilgængelig på et tidspunkt mellem 9. og 15. december i år.

Der er efter sigende ikke nogen fare for, at de berørte enheder vil fejle, før firmwareopdateringen bliver gjort tilgængelig.

Datatab

Hvis firmwaren ikke installeres i tide, vil SSD’en fejle. Afhængig af opsætning vil det i mange tilfælde være umuligt at genoprette dataene på enheden. I stedet skal de hentes fra en sikkerhedskopi eller spejling.

HPE oplyser på denne side om et værktøj, som kan bruges til at se, hvor mange timer den enkelte SSD har været i drift.

Svensk lagringscrash

Harddiskene i flere tusinde pc’er på svenske hospitaler har fejlet de seneste månederne, konkret Elitedesk-pc’er fra HP. Det er sandsynligt, at disse maskiner var udstyret med SSD’er og ikke harddiske, det har i hvert fald ét af hospitalerne oplyst.

Dermed kan det være et tilsvarende problem som det tidligere nævnte, som har ramt de svenske hospitaler og andre brugere af de aktuelle computere. Hos politiet i Sverige er mindst 2.500 lagringsenheder efter sigende crashet det seneste år.

Artiklen er fra digi.no.

17 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
15
2. december 2019 kl. 19:31

Ja, det gør den.

Moderne diske, både flash & rust, ved en masse om de kvantemekaniske mekanismer der får de lagrede bits til at udviskes og en af måderne de kommer det i forkøbet er at vide præcist hvor lang tid, i "wall-clock-time" det er siden data blev skrevet.

Hvis du har dine data kær, skal du ikke give dig til at lære om hvor få atomer der er per bit nu om dage.

14
2. december 2019 kl. 19:10

Den skal modtage, returnere og slette blokke når man beder den om det og sige fejl når det går galt.

13
2. december 2019 kl. 13:20

Linux-kernen havde et tilsvarende problem: en oppetid på 491 dage fik maskinen til at boote. Det blev løst ved at lade overflow ske 5 minutter efter boot:https://lwn.net/Articles/22874/

12
2. december 2019 kl. 12:35

Jeg har før set gode gamle SAS hdd'er lave wrap-around ved 65K timer (uint16) og køre ganske glimrende videre fra 0, så det er utilgiveligt at disse SSD'er dør af det.

11
2. december 2019 kl. 12:31

Nu er det efterhånden et stykke tid siden jeg sidst har rodet med SAN. Men sidst jeg var involveret i et sådan projekt valgte vi faktisk at have forskellige diske i netop for at undgå at alt var for ens.

Langt de fleste (mig bekendt) køber nye SAN færdig-konfigureret, så det er ofte ikke noget man har let ved at kontrollere, man køber ikke individuelle diske, i hvert fald ikke i større deployments.

Og for at gøre det værre, så putter de fleste vendors deres eget logo på diskene, og putter flere "tilsvarende" diske under samme part number, så der er reelt ingen kontrol med hvilken producent diskene kommer fra.

8
2. december 2019 kl. 11:13

Hehe, for nogen tid siden skete det samme for mig, med en Crucial m4, bare efter blot 5184 timer. Heldigvis var den OK efter en genstart, og så var der en time til at søge efter en forklaring, hente ny firmware og opdatere den.https://www.storagereview.com/node/2676

Mon ikke det kan rettes ved at tillade en helt simpel wrap-around, uden overflow-check?

7
2. december 2019 kl. 10:43

at man havde lært af Y2K-problemet, at man skal bruge rigeligt med bits/cifre til tidsangivelser. At bruge (endda signed!) 16-bit heltal til at tælle timer er bare dumt.

Gad vide om opdateringen blot ændrer tallet til 16-bit unsigned, så man kan komme op på 65565 timer, før disken fejler. På det tidspunkt har diskene været brugt i over 7 år, og så mener de måske, at de nok alligevel er skiftet ud.

6
2. december 2019 kl. 09:26

valgte vi faktisk at have forskellige diske i netop for at undgå at alt var for ens

Der er mange controllere, der forlanger at diskene har samme type. Og mange har den praksis at diskene skal bare være af samme type i et RAID.

diske med forskellige produktionsdato, anses mig bekendt som best pratice

Det er jeg helt enig i. Desværre hjælper det ikke i dette tilfalde. De har alligevel været online i ca. lige lang tid. Og så dør næste diske før den første er genbygget.

Jeg ser også et andet stort problem. Hvis et stort cluster af diske pludselig dør og skal genskabet fra backup. Har man så diske at genskabe dem til? Eller er de pludselig i restordre? Det samme er måske sket for andre virksomheder, så pludselig er de har diske i høj kurs.

Jeg har engang prøvet at skulle udvide et cluster og derfor skulle vi bestille nogle store diske. Vi fandt nogle butikker, der havde den rigtige type. Ingen af dem havde nok af dem på laget i forhold til det antal vi skulle bruge. Det er selvfølgelig fint, fordi det øger chancen for at de ikke er produceret samme dag. Så vi valgte at dele bestillingen over 3 forskellige butikker.

Desværre, da vi havde bestilt hos en, så havde alle de andre udsolgt. Diskene lå nemlig hos grosisten. Og de havde den samme grosist. Og vi måtte vente i flere uger.

5
1. december 2019 kl. 13:32

At bruge diske med forskellige produktionsdato, anses mig bekendt som best pratice.

Det lyder dog ikke til at have løst problemet her, da hvis de er installeret samtidig, jo stadig har kørt lige lang tid.

4
30. november 2019 kl. 23:07

“ Denne type fejl kan medføre at samtlige diske i dit SAN eller NAS fejler nøjagtig samtidig.” Nu er det efterhånden et stykke tid siden jeg sidst har rodet med SAN. Men sidst jeg var involveret i et sådan projekt valgte vi faktisk at have forskellige diske i netop for at undgå at alt var for ens.

3
30. november 2019 kl. 23:05

Hvis man en eller flere, af de nævnte solid state diske.

2
30. november 2019 kl. 12:20

Det lyder mærkeligt, at alle data skulle være umulige at genoprette efter "crash" af denne type. Måske bliver krypteringsnøglen overskrevet, så data ikke længere kan dekrypteres? En anden forklaring kunne også være, at mapping-tabellen overskrives (og så kræver det en efterretningstjeneste at genskabe indholdet).

1
29. november 2019 kl. 18:57

Denne type fejl kan medføre at samtlige diske i dit SAN eller NAS fejler nøjagtig samtidig. Diskene har af gode årsager kørt præcis lige lang tid...