Bepaalde sas-ssd's in HPE-servers gaan zonder update na 40.000 uur kapot

Hewlett Packard Enterprise waarschuwt dat bepaalde sas-ssd's van 800GB en 1,6TB na 40.000 uur defect raken. De fabrikant heeft een firmware-update beschikbaar gesteld die voorkomt dat dit gebeurt. De ssd's kunnen vanaf oktober dit jaar kapotgaan.

Gebruikers van HPE-servers met de getroffen ssd's moeten de HPD7-firmware installeren om te voorkomen dat de ssd's na 40.000 uur de geest geven. Het gaat niet om de tijd sinds de aanschaf, maar om het daadwerkelijke gebruik in uren. De periode komt overeen met een tijdsbestek van 4 jaar, 206 dagen en 16 uur.

HPE zegt op de hoogte te zijn gebracht van het probleem door een leverancier van ssd's. De fabrikant noemt die leverancier niet bij naam, maar het voorval lijkt op het probleem dat eind vorig jaar aan het licht kwam. Toen bracht HPE een update uit voor sas-ssd's die na 32.768 uur stuk zouden gaan. HPE benadrukt dat dit niet om hetzelfde voorval gaat.

Wat het probleem precies veroorzaakt, meldt HPE niet. De fabrikant waarschuwt dat ssd's onherstelbaar beschadigd raken als de firmware-update niet wordt toegepast. Ook is de kans groot dat andere ssd's, die gelijktijdig met de getroffen ssd's in gebruik zijn genomen, eveneens de geest geven.

De desbetreffende ssd's zitten in verschillende HPE-servers en verwante producten die in de afgelopen jaren zijn verkocht. Vanaf oktober dit jaar bereiken de ssd's de limiet van 40.000 uur als ze zijn aangeschaft toen de producten voor het eerst op de markt kwamen.

Getroffen ssd's
HPE-modelnummer	HPE-sku	Productnaam
EK0800JVYPN	846430-B21	HPE 800GB 12G SAS WI-1 SFF SC SSD
EO1600JVYPP	846432-B21	HPE 1.6TB 12G SAS WI-1 SFF SC SSD
MK0800JVYPQ	846434-B21	HPE 800GB 12G SAS MU-1 SFF SC SSD
MO1600JVYPR	846436-B21	HPE 1.6TB 12G SAS MU-1 SFF SC SSD

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (85)

32.768 is de maximum waarde van een signed 16 bit waarde (2^15). Dus dat is alvast duidelijk het gevolg van een maximum waarde (of overflow zoals we wel een zeggen). Die 40000 uren is een andere zaak, dat is niet echt een getal wat bij mij overkomt als een limiet van een data type, maar misschien wel in de application logic (bijvoorbeeld een tabel van 40000 elementen waarin wat statistiek wordt bijgehouden)

In het artikel wordt over uren gesproken, maar het kan zomaar zijn dat de statistiekenteller iin de ssd's in minuten of zelfs seconden werkt. Dan krijg je veel grotere getallen.

Hoe kan dit met een firmware update opgelost worden? Zijn die dingen voorgeprogrammeerd om kapot te gaan ofzo?

Mijn vermoeden is dat ze inderdaad voorgeprogrammeerd zijn om kapot te gaan, maar niet met opzet en al zeker niet met voorbedachte rade.

Er zal in de firmware een ergens stukje statistiek worden bijgehouden en dit gebeurd met een bepaald datatype. Dit datatype zal zijn limiet bereiken is mijn vermoeden en deze firmware zal dit herstellen.

[Reactie gewijzigd door Pdvdp81 op 25 maart 2020 10:36]

Hoe moet ik me dat 'kapot' gaan dan voorstellen?
Fysiek gaat er toch niets stuk enkel een 0 die 1 wordt waardoor de data ontoegankelijk wordt?

De meest logische redenatie is dat de controller van de SSD crashed. Als deze crashed tijdens boot heb je niet eens de kans om een nieuwe firmware te kunnen crashen en is de data effectief “weg”. Zeker aangezien een SSD controller een page mapping bijhoudt (“dit logische blok staat in dit fysiek stukje flash”) en dit niet te herstellen is door simpelweg een andere controller er op te solderen.

Mja.. dat klinkt echt zo onlogisch.
Waarom die page mapping table bijhouden in de controller? Waarom niet gewoon (een cold copy) wegschrijven naar het flashgeheugen?

Met RAID opstellingen heb je hetzelfde achterlijke probleem.
Weet niet of het met alle RAID controllers/software RAID opstellingen zo is en of dat nog steeds een issue is maar ik weet wel dat je problemen kon hebben als je HDD's (fysiek) omwisselde of je RAID kaart verving of zo. Hier ben ik iig in het verleden wel eens tegen aan gelopen.
Hoezo niet gewoon, ongeacht of je hardware/software RAID gebruikt, even op élke HDD op de eerste sectors of zo wat metadata schrijven die de controller/computer kunnen vertellen dat deze HDD onderdeel is van array met naam X, configuratie Y en dat het disk Z in de range is? Okay cross-compatibility is natuurlijk moeilijk (want verschillende fabrikanten etc), maar het is toch gewoon super slecht ontwerp als ik 2 HDD's die onderdeel van dezelfde RAID array zijn fysiek omwissel op de RAID controller kaart dat dan ineens die kaart dat niet kan detecteren en stilzwijgend accepteren? Dát noem ik echt een ontwerpfaal van heb ik jou daar!

[Reactie gewijzigd door Ayporos op 25 maart 2020 16:17]

Waarom die page mapping table bijhouden in de controller? Waarom niet gewoon (een cold copy) wegschrijven naar het flashgeheugen?

Omdat die mapping bij iedere schrijfactie wijzigt. Dit omdat de wear leveling er voor zorgt dat alle blokken (ongeveer) even vaak beschreven worden.

Zou je deze tabel op het flashgeheugen zetten dan moet je weer bijhouden waar, want als je er een fixed page voor aanwijst dan overschrijf je die ene page bij IEDERE write.

Met RAID opstellingen heb je hetzelfde achterlijke probleem.

Nee, bij RAID wil je weten welke schijven lid zijn van de array en wat de instellingen van de array zijn. Dit wijzigt zo goed als nooit, en dat kan inderdaad prima op de schijf geschreven worden. De meeste RAID-controllers doen dat ook.

Dat is echter een compleet andere soort data (en véél statischer) dan de page mapping van een SSD.

Vaak gebruiken ze voor dit soort statistieken (bijhouden of iets al gebruikt is, of juist is vrijgegeven) een truukje wat rekening houd met de specifieke eigenschappen van NAND flash.
Met NAND flash kun je alleen een 1 in een 0 veranderen. Als je de andere kant op moet, dan moet je een heel blok inlezen, in het geheugen de data aanpassen, blok wissen en weer wegschrijven.
Dat laatste kost dus een complete schrijfactie van een heel blok (vaak meerdere pages/sectoren), terwijl een bitje van 1 naar 0 omzetten nog steeds dezelfde schrijf-actie is als het vorige bitje in hetzelfde blok wat je op die manier omgezet hebt. (let wel, voor multi-level cellen is dit iets ander verhaal)

Oftewel als je bij moet houden welke blokken vrij zijn om te gebruiken en welke blokken niet meer in gebruik zijn en dus gewist kunnen worden, kun je dat doen in 2 "tabellen". Elk bitje verwijst dan naar een blok. En het mooie is dat alle bitjes een voor een omzetten van een 1 naar een 0 effectief nog steeds dezelfde schrijfactie is.
Zolang je niet een erase hoeft te doen op het blok is het eigenlijk nog steeds dezelfde schrijf-actie. De 'wear' komt namelijk door het wissen.

De uren teller is typisch zoiets wat je heel goed in een rij van bitjes kunt opslaan op flash geheugen van de schijf zelf, net als wear level statistieken.
Mijn vermoeden is dat het uren-tellertje iets verder door schrijft dan bedoeld.
Stel dat je het lijstje van "ongebruikte sectoren, klaar om te wissen" als eerste blok hebt na het uren tellertje, dan krijg je "vinkjes" in een tabel die gebruikt wordt om bij te houden welke blokken gewist kunnen worden.

Voor een gewone schijf met een enkel filesysteem zal dit in eerste instantie niet meteen catastrofaal zijn.
Uiteraard heb je data verlies, maar het gros van de data zal nog wel benaderbaar zijn en de fout zal vrij snel duidelijk worden.

Echter dit soort schijven wordt gebruikt in systemen die een of andere vorm van erasure coding gebruiken.
Dat wil zeggen dat je de data in kleine brokjes opdeelt en die parallel aan heel veel schijven aanbiedt.
Op die manier heb je een gegarandeerde transfer rate, gelijkmatige load op alle schijven en goede lees- en schrijf-performance. (voor systemen met petabyte opslag en/of high-availability opslag)
Dit is namelijk veel meer fout-tolerant dan welke RAID-oplossing dan ook.

Nadeel is alleen wel dat plotseling missende blokken op vrijwel alle schijven in je systeem (want tegelijk aangeschaft, gelijk aantal operationele uren) je hele systeem onderuit schoffelt.
Zo'n erasure code systeem is namelijk prima in staat om een significant deel van zijn schijven te verliezen (factor is te bepalen bij inrichten van het systeem), maar niet als alle schijven tegelijkertijd stuk gaan.
Als het om echt belangrijke data gaat, zoals databases van banken of actuele data van luchtverkeer, dan heb je vaak meerdere van dit soort systemen op verschillende locaties staan die per 'kast' een erasure code systeem hebben, maar met elkaar ook nog zo'n laag vormen. Dan heb je het wel over de "iets prijziger" storage oplossingen.
Met hdd's zit je op een rack van 4.7 PB ruwweg op 8 ton. Voor een SSD-variant zal dat iets meer zijn.

Maar het vervelende is alleen wel dat zelfs geo-spread racks min of meer hetzelfde aantal power-on uren zullen hebben als het als een geheel is aangeschaft.
Toch vervelend als je high-availability systeem een paar dagen of mogelijk langer offline is.

[Reactie gewijzigd door TD-er op 26 maart 2020 01:16]

Bedankt voor de verduidelijking, het bevestigt wat ik zo (ong) dacht

Dat inderdaad. Het is al vaker bij SSD's gebeurd dat er een firmware bug in zat die pas na lange tijd ineens de boel omzeep bracht. Met een firmware update was dit dan wel weer op te lossen maar toch vervelend als het gebeurd.

Wij hebben op het werk problemen gehad met HP Notebooks met een SSD die SQL-server erop hadden. Het constante repliceren zorgde ervoor dat de meeste SSD's binnen twee maanden er geen zin meer in hadden. Zo af en toe vraag ik mij af of een SSD de oude en beproefde HDD wel helemaal kan vervangen.

Bij high end SAN apparatuur zitten wat functies ingebouwd.
- De grootste winst is de cache. Daardoor hoeft niet alles meteen weggeschreven te worden
- write delay, folding en Coalescing zorgt er voor dat data die 30 seconde niet veranderd is pas wordt weggeschreven
- SSD's in high end arrays zijn vaak EFD (Enterprise Flash Disks). het grote verschil is dat hardwarematig extra storage is die geactiveerd wordt nadat stukken kapot zijn. meestal zit er dus 2x zo veel in waardoor de EFD zelf nieuwe blokken activeert. Daardoor gaat de EFD langer mee.

Dat noemen we overprovisioning, en dat kan je thuis ook heel makkelijk doen door niet alle ruimte op je SSD te alloceren. Ik houd zelf 20% vrij, naast de overprovisioning die de fabrikant al heeft toegepast.

Bij tests die ik (jaren terug) in HPE's performance test center deed, hielden ze zelfs 50% aan.

Dat kan wel mits de firmware goed is en je ook een SSD koopt die past bij je gebruik.
Want ja vaak schijven is voor sommige TLC of QLC drives echt niet goed.
Dan kan je beter SLC of MLC drives hebben als je veel moet schrijven maar die zijn weer een stukje duurder.

Twee maanden is trouwens wel heel kort. Er zijn genoeg schrijf tests geweest die aantonen dat Desktop drives al jaren mee kunnen gaan als je de hele dag door data weg schrijft.

[Reactie gewijzigd door Astennu op 25 maart 2020 12:10]

Twee maanden is trouwens wel heel kort. Er zijn genoeg schrijf tests geweest die aantonen dat Desktop drives al jaren mee kunnen gaan als je de hele dag door data weg schrijft.

Het was inderdaad erg, erg kort. Het heeft mij ook heel wat tijd gekost om uit te leggen dat een SSD dit makkelijk voor een aantal jaar aankan. Uiteindelijk toch gezwicht en overgaan op normale HDD's.

Zou niet nodig moeten zijn misschien is het de moeite om nog eens een keer een test te doen met goede MLC of SLC SSD's.

Dat was het probleem een beetje, wij (beheer) hebben hierin weinig te kiezen. Het moest een product zijn die stock was met eventueel wat kleine aanpassingen (lees: geheugen en randapparatuur). Het werd uiteindelijk een HP 840 met een TLC SDD. Ondanks dat er wel een database op stond met tienduizenden regels moest de SDD het makkelijk aankunnen. Helaaas pindakaas, dat was dus niet zo. HP trok zijn schouders op.

Ik snap het. Zeker als je veel machines moet uitrollen wil je niet overal zelf SSD's moeten vervangen voor de juiste exemplaren. Maar wel raar dat HP support niets kon doen.

Een unsigned int gaat tot 4294967295. In 40.000 uur kun je dan zo ongeveer 30 keer per seconde iets opslaan. Klinkt niet als onwaarschijnlijk dat intern inderdaad ergens een sequence wordt bijgehouden voor bv optimalisatieslagen.

Ah niet aan gedacht. Dat is inderdaad de meest logische verklaring.

(hopende dat het niet met voorgedachte rade is)

[Reactie gewijzigd door defixje op 25 maart 2020 10:26]

Nou in dit geval is dat het niet. Een server die binnen 5 jaar volledig en catastrofaal de geest geeft is een enorm probleem voor bedrijven. Die is dan nog niet afgeschreven en zal ws ook nog in support contract vallen. Zou heel dom zijn van HPE om dat dan express te doen.

Edit "Reply @defixje" Denk je dat serieus dat ze dat express doen? Ieder (beursgenoteerd) bedrijf is als de dood voor imagoschade! Een support contract is bijzonder onrendabel als je voor iedere server moet uitrukken voor support. De berekening van het tarief van een supportcontract wordt gebaseerd op statistieken. Als ze programmeren om express stuk te gaan moet er geld bij. Bijzonder onwaarschijnlijk!

[Reactie gewijzigd door InsanelyHack op 25 maart 2020 13:01]

exact. Dat was precies mijn punt. Ik denk dat je op @defixje wilde reageren?

Dit is bij consumenten prul soms nog wel eens de vraag, maar op enterprise nivuea is dat het niet. Als HPE dit willens en wetens zouden doen dan worden ze binnen no-time voor de rechter gedaagd en kost het hun veel meer dan dat het op kan leveren. Naast dat ze onder service alle getroffen servers mogen oplappen en kijken of ze de data terug kunnen halen.

Ook op enterprise nivo wordt er gewoon gewerkt met geplande achteruitgang van kwaliteit hoor.

Het gaat niet echt stuk, maar een monitor gaat net even wat minder licht geven na 5 jaar, een ssd gaat net even wat minder hard draaien, een warning gaat net even op een iets lagere waarde al naar boven komen.
De fabrikant claimt dat het allemaal gebeurt om te zorgen dat het minder snel slijt en dat het juist beter werkt hierdoor, alleen in de praktijk vervangt iedereen al het spul want men gaat vrezen dat er meer aan de hand is.

Een logbestand dat over een grens heen gaat en iets overschrijft. In plaats van terug naar af te gaan. Van iets vergelijkbaars schijnen sommige auto's last te hebben...

Die autos loggen gewoon te veel en schrijven die ssds gewoon helemaal naar de knoppen.

Klopt, de oorzaak is nog steeds loggen. Het resultaat is een defect. Alleen de limiet die wordt bereikt is dan die van cycles versus die van opslagruimte.

maar het gaat dus niet een grens over waardoor er iets overschreven wordt (je insinueerd iets softwarematigs als een bufferoverflow of integer overflow). Nee die drive wordt fysiek gewoon kapot geschreve doordat er teveel data in te korte tijd naartoe geschreven wordt.

Nee die drive wordt fysiek gewoon kapot geschreve doordat er teveel data in te korte tijd naartoe geschreven wordt.

Grappige manier van zeggen als je bedenkt dat de oplossing is : Meer data in een veel kortere tijd ernaartoe schrijven

Je moet niet elke kilobyte los gaan schrijven (want dan heb je met een megabyta al 1000 schrijfacties) maar je wilt die kilobytes bufferen en in 1x wegschrijven als het een megabyte geworden is, zodat je 999 schrijfacties uitspaart...

Nee het probleem is hier fysiek de nand cellen die te vaak beschreven zijn. Die gaan achteruit. Het aantal schrijfacties maakt niet zozeer uit maar het aantal keer dat een bepaalde cel herschreven is. Dat gaat echter per bytechange. En met TLC en QLC dus drie of vier bytes per cel dus 3 tot 4 keer vaker dan bij SLC.

Of je nou 100MB in 1 keer wegschrijft of in 100 delen maakt dan alleen uit in de overhead zaken. Niet in de daadwerkelijk weggeschreven hoeveelheid.

Klinkt als een signed int die over de kop gaat waarna de huidige firmware zegt "-32000 gedraait, dat kan natuurlijk nooit, ik zal wel kapot zijn dus ik zet mezelf uit".

Een signed int is 32.768, geen 40.000.

Klopt, maar als die 40.000 uur in msec worden uitgedrukt in de firmware, dan kom je met 40k uur een heel eind in de richting van wat er in een 32-bit int past. Ik heb geen zin om het uit te rekenen, ik wil alleen maar zeggen dat omdat wij het omschrijven als "40k uur" dat de SSD controller het misschien heeft over 1.44E+11 msec.

Ze gaan niet kapot, ze gaan corrupt, mogelijks had Tweakers dat anders kunnen verwoorden.

"result in drive failure and data loss at 40,000 hours of operation and require restoration of data from backup if there is no fault tolerance,"

Met drive failure bedoelen ze inderdaad failure maar in server termen wilt dit gewoon zeggen dat deze een probleem heeft. In consumenten wereld spreek je van disk failure & disk corruption.

Dat heeft te maken omdat je in server wereld geen onderscheid maakt waar het onderliggend probleem is, je ontwerpt een systeem waarbij je een risico hebt dat een disk een failure krijgt. Of die disk dan al dan niet fysiek defect is of besloten heeft om zijn data corrupt te maken, dat maakt niet uit, je trekt die disk eruit en je stopt een andere.

In consumenten wereld, als een disk corrupt geraakt, dan heb je gewoon pech en doe je een reïnstall.

Het probleem met SSD's, en wat HP ook aangeeft als je de bron verder leest, die dingen hebben nogal de neiging om gelijktijdig defect te gaan.
Als ze bijvoorbeeld door hun read/writes zitten, dan zitten al je disks plots door je read/writes.

Als deze bug actief word, dan is het niet 1 disk die dit probleem heeft, het zijn ze allemaal en min of meer op hetzelfde moment. Dat wilt zeggen dat je u server kwijt speelt, RAID gaat niet helpen.

Nu dacht je slim te zijn en 2 of meerdere servers te plaatsen, die zijn allemaal van hetzelfde type, gekocht op hetzelfde moment en in dienst gezet op hetzelfde moment.

Dat is waarom HP dit aan de heel grote klok hangt, je kan een volledige servercluster verliezen aan dit grapje. En of die disken dan al dan niet fysiek defect zijn, dat doet er zelfs niet toe.

In consumenten wereld, als een disk corrupt geraakt, dan heb je gewoon pech en doe je een reïnstall.

Nope, ook in de consumentenwereld gooit men corruptie uit hardware gewoon weg.
Schijven kosten niets meer tegenwoordig en zijn veels te groot geworden om het risico op een 2e corruptie te lopen.

Nu dacht je slim te zijn en 2 of meerdere servers te plaatsen, die zijn allemaal van hetzelfde type, gekocht op hetzelfde moment en in dienst gezet op hetzelfde moment.

Dan ben je geen enterprise beheerder maar gewoon een ontzettend domme oen. Een beetje beheerder mixt allerlei systemen en typen door elkaar heen, puur vanwege juist het risico dat als er ergens een productiefout inzit, dat dan niet alsnog alles down gaat.

In een wereld van standaardisatie is dat in de praktijk nogal heel vaak hetzelfde systeem. Uiteraard steekt niet heel je datacenter vol met server Type X maar als je 2 servers hebt met een loadbalancer ervoor, dan zijn dat 2 identieke machines.
Of steek jij een HP server met AMD en een Dell server met Intel met daar exact dezelfde software op?

Nog nooit gezien hier.

Of steek jij een HP server met AMD en een Dell server met Intel met daar exact dezelfde software op?

Nog nooit gezien hier.

Extreme uitzonderingen daargelaten, yep dat doen wij. We mieteren er VMWare ESXi op en voor de rest is het puur afhankelijk van andere software etc welke VM's er op die bakken belanden.

Of het zijn gewoon alletwee storagebakken en dan gaat er ook dezelfde software op en mag wederom andere software uitmaken welke storage waar en op welk moment geplaatst moet zijn.

Ik moet gewoon Vm-hosts tegen een bepaalde capaciteit en SLA hebben met een bepaalde storage en waar die exact staan op welk moment dat interesseert me echt geen ene hout.

Lekker HA-en op een cluster met CPU's van verschillende vendors.

EVC werkt nog steeds niet tussen Intel en AMD hoor.

Does EVC allow AMD and Intel CPUs to be vMotion compatible?

No. An EVC-enabled cluster only allows CPUs from a single vendor in the cluster. VirtualCenter and vCenter Server do not allow you to add a host from a different CPU vendor into an EVC-enabled cluster.

Bron

Misschien een andere SMART-waarde dan de vorige keer een maximum bereikt. Feitelijk zou je dat voorgeprogrammeerd kunnen noemen, maar niet bewust.

[Reactie gewijzigd door MN-Power op 25 maart 2020 10:29]

Klinkt heel erg naar een integer overflow of iets in die richting...
Men houd ergens in de firmware een count bij van het een of ander, zo lang die netjes iedere interval (seconde/minuut/dag/tick) omhoog gaat vergeleken met de vorige waarde dan is alles goed. kom je aan het eind van die integer en rolt deze dus terug naar 0 dan is er een probleem en is het ding "stuk"

Een fix is waarschijnlijk om een simpele check te maken die zegt als de laatste waarde X was dan mag de volgende waarde 0 zijn (misschien met een extra waarde om het aantal keren dat die rollover gebeurt is bij te houden) of misschien simpel weg de integer vervangen door een double etc... vaak zijn het simpele dingen en is het niets anders dan een developer die vergat dat dit soort dingen nu eenmaal erg lang mee gaan. en een variable een maximale grote heeft.

De controller in de SSD bepaald hoe de schrijfacties verdeeld worden. Zeker met stacked chips wordt er niet 1 bitje, maar een hele serie bitjes in 1 keer weg geschreven. Met hoe nvram werkt (vast houden van elektronen of ze er juist uit trekken) raakt de chip licht beschadigd met elke verandering (schrijf actie dus).
Om dit op te vangen hebben meeste ssd's ook reserver capaciteit om defecte blokken te vervangen.

voor meer details check deze uitleg.
edit: meer info over hoe de transistors zelf werken op wikipedia

[Reactie gewijzigd door Aragnut op 25 maart 2020 10:36]

" Ook is de kans groot dat andere ssd's, die gelijktijdig met de getroffen ssd's in gebruik zijn genomen, eveneens de geest geven. "

Hoe dat? Iemand enig idee?

RAID setjes in dezelfde server. Die worden vaak gelijktijdig in gebruik genomen. Dan gaan ze allemaal in één keer tegelijkertijd kapot en is je data pleite.

Dit zijn dezelfde type SSD's, dat bedoelen ze. In een RAID set is dat vaak het geval.

[Reactie gewijzigd door EquiNox op 25 maart 2020 13:04]

Als ze allemaal op exact 40.000 uur stuk gaan, en je koopt 30 servers, dan is de kans heel groot dat je ze alle 30 (ongeveer) tegelijkertijd hebt aangezet. Ook als er maar één zo'n SSD per server in zit, geven ze toch binnen een (paar) uur van elkaar de geest.

Ook kan het zijn dat er meerdere van die SSD's in één server zitten (of eigenlijk is dat zelfs waarschijnlijker dan dat het er maar één is), en dan zijn ze natuurlijk al helemaal allemaal tegelijkertijd aan die 40.000 uur.

Volgens mij staat het er een beetje lomp, maar bedoelen ze het volgende :
Stel jij hebt 1 Raid-array van 20 schijven, 10 daarvan zijn van dit type.
Normaliter kan er bij een Raid-array best 1 schijf uitvallen, of 2... Maar als er in 1 dag 10 uitvallen, dan heb je aan de data op die andere 10 ook niets meer.

Oftewel ook al zijn die 2e 10 technisch nog perfect in orde, toch ben je de data erop kwijt.
En zeker bij enterprise systemen gaat men niet kijken wat er nu exact stuk is aan een complete stukke RAID-array, men vervangt gewoon die complete RAID-array met 20 nieuwe schijven, aangezien het veel en veels te duur is om die hele raid array uit elkaar te halen en de schijven los te gaan testen op kwaliteit etc.

Oftewel praktisch als je 10 van deze schijven in een 20-schijfs RAID-array hebt zitten mieter je de complete RAID-array inclusief schijven weg als die zichzelf niet meer kan recoveren.

Hoe zit het met garantie als je te laat update?

Vanuit de Nederlandse wet lijkt mij dit sowieso een ondeugdelijk product en dan zul je toch recht hebben op reparatie, vergoeding o.i.d.
Qua garantie kan HP er voorwaarden aan verbinden en dus inderdaad eisen dat je z.s.m. de nieuwste updates installeert.

Met die redenatie kun je ook een auto waar een terugroepactie op zit als ondeugdelijk product bestempelen.
Dat lijkt me niet de bedoeling. Ook hier biedt de fabrikant in de vorm van een firmware update de mogelijkheid aan om het product weer in orde te maken. Daardoor is het m.i. geen ondeugdelijk product (meer).

Ten eerste door de aangeboden update lijkt mij dat er sowieso niet onmiddellijk sprake is van een ondeugdelijk product. Een en ander hangt natuurlijk ook af van de inspanningen die geleverd wordt om dit bericht over te brengen bij de consument. Bij een product van meer dan 6 maanden moet je daarnaast zelf kunnen bewijzen dat dit product niet levert wat je er redelijkerwijs van had mogen verwachten. Dat lijkt me na :4 jaar al geen eenvoudige opdracht, maar misschien dat het met een uitdraai van dit artikeltje lukt.

Dan is echter de vraag op welke vergoeding je eventueel aanspraak op wil maken. Wat is de waarde van een schijf van ca. 200 / 300 E na een afschrijving van bijna 5 jaar ? Dat lijkt me vrijwel nihil en dus heb je nergens recht op. Bewijzen dat je enorme gevolgschade heb geleden a.g.v. dataverlies lijkt me ook onmogelijk. Naast de bewijslast (die grotendeels verloren is gegaan) roept dat namelijk onmiddellijk de vraag op waarom je de data bijv. niet beter beschermd heb en inderdaad gevraagde updates en ondersteuning niet hebt opgevolgd.

Als je rekent op een vergoeding, reken er maar niet op...

Afgelopen maand kreeg ik ook al van Dell een waarschuwingsmail ook 40000uur
zal wel geen toeval zijn aangezien veel schijven maar bij een paar makers vandaan komt.

Heb je link naar die firmware?

Die heb ik helaas zo niet.
Dit sturen we aan via Dell Openmanage, die haalt zelf de firmware op.
En afhankelijk van welke firmware, moet dell dit vrijgeven( NAS firmware bijvoorbeeld)

Klinkt als dezelfde bug waar Dell eerder dit jaar voor waarschuwde met specifieke SanDisk SSDs.
Het probleem met de Dell SSDs heeft dezelfde symptomen en triggered ook na 40000 uur.

Was daar ook een firmware update voor? Jaartje geleden nog gekeken en nieuwste uit 2014 ofzo

Volgens mij is het deze:

Doet mee een beetje denken aan de Crucial M4 SSD van enkele jaren terug. Die zorgde voor spontane vastlopers in Windows na een X aantal uur in gebruik te zijn geweest. Minder drastisch dan een SSD wat kapot gaat, dat dan weer wel. En ook met een firmware update was dit probleem te verhelpen.

Dat is nog eens planned obsolence!

Geintje natuurlijk, maar wel vervelend dat dit juist bij servers gebeurt. Die zijn meestal wat minder makkelijk bereikbaar dan je desktop of laptop en hebben vaak meerdere exemplaren van de disk aanwezig...

Helaas is de tijd aan het veranderen. Vroeger was enterprise spul degelijk. Tegenwoordig is het maar afwachten. Intel had er een tijd geleden ook last van. https://support.microsoft...ive-after-1700-idle-hours

Zo ook nog een andere reeks daar van kan ik de link zogouw niet vinden. En dan binnen 8 uur gewoon 2 ssd's naar de haaien jammer van je raid 5 dan in dat geval...

Het grote gevaar is niet dat deze SSDs stuk gaan. Ze zitten vaak in een RAID array dus verlies van een device zou getolereerd moeten kunnen worden.

Het grote gevaar met deze bug is dat ze allemaal tegelijk stuk gaan en daar kan RAID niet tegen beschermen.

En zo'n situatie zal zich voor doen op alle servers. Mocht je een aantal machines tegelijk in gebruik hebben genomen dan vallen ze min of meer tegelijk uit.