Bepaalde HPE-sas-ssd's gaan kapot na 32.768 uur

Hewlett Packard Enterprise waarschuwt dat bepaalde sas-ssd's die het bedrijf gebruikt in zijn servers, onherstelbaar defect raken na 32.768 gebruiksuren. Dat komt door een fout in de firmware. HPE heeft firmware-updates beschikbaar gesteld die het probleem voorkomen.

HPE zegt dat het door een ssd-leverancier op de hoogte is gesteld van het probleem. De ssd's raken defect door een fout in de firmware. Die treedt op na exact 32.768 gebruiksuren, ofwel 3 jaar, 270 dagen en 8 uur. HPE gebruikt de getroffen ssd's in verschillende producten in zijn server- en storage-lijn.

De problemen treden op bij ssd's die een firmwareversie hebben die ouder is dan HPD8. Als de fout toeslaat, raakt de ssd onherstelbaar beschadigd. Volgens HPE kan de data niet meer hersteld worden. Bovendien is de kans volgens HPE groot dat andere ssd's, die gelijktijdig met de getroffen ssd geïnstalleerd zijn, ook stuk gaan.

HPE heeft voor acht ssd's firmware-updates uitgebracht. Nog eens twaalf getroffen ssd's krijgen de firmware-update in de week van 9 december. HPE merkt op dat het probleem bij de ssd's die de update later krijgen, nog niet kan optreden, omdat die nog niet zo lang op de markt zijn. HPE heeft instructies en firmware-updates op zijn support-pagina gezet.

Volgens de fabrikant zijn producten in de volgende series getroffen: ProLiant, Synergy, Apollo, JBOD D3xxx, D6xxx, D8xxx, MSA, StoreVirtual 4345 en StoreVirtual 3200. Producten uit de serie 3PAR, Nimble, Simplivity, XP en Primera hebben niet te maken met het probleem.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (138)

Als iemand zich afvraagt waarom specifiek 32768 uur: dit is een signed 16-bit integer. Oftewel eenzelfde soort bug als het recente probleem met GPS of het probleem dat 32-bits systemen kunnen gaan krijgen met de tijd in 2038.

Maar dan is nog de vraag waarom de firmware (apart) het aantal uren telt (en consequent waarom er voor een signed integer gekozen is).

Maar dan is nog de vraag waarom de firmware (apart) het aantal uren telt (en consequent waarom er voor een signed integer gekozen is).

Het eerste omdat je dan bij kunt houden hoeveel uren de schijf heeft gedraaid. Het tweede omdat er een programmeur niet goed genoeg over heeft nagedacht.

uren veranderen in dagen dan kan hij 24 keer zo lang mee en heb je nog genoeg om te weten hoeveel dagen de ssd gebruikt is ... ik ben een man van simpele oplossingen :-)

De standaard is om het aantal runtime hours te tonen, niet het aantal dagen.

Wat de standaard is laat ik me niet over uit :-) lijkt me makkelijk om het probleem te omzeilen door er dagen van te maken dan kom je 24 keer zo lang toe. Wil je echt een uren cijfer dan kan je nog altijd * 24 doen in je firmware ... dat is alleszins beter dan een nietwerkende lijkt mij.

Aantal uren is zuiverder. Niet elke dag heeft exact 24 uur -> zomer/wintertijd.

edit: aanpassing om uren naar dagen te berekenen en dan 2 variabelen te gebruiken lijkt me meer werk dan om van een signed integer een ander variabel type te maken die veel groter kan worden. Dat is enkel de variabele declaratie aanpassen.

[Reactie gewijzigd door Amasik op 27 november 2019 16:48]

Dagen werkt niet om dat de schijf niet altijd aan staat. Dus als je schijf elke dag een paar wisselende uren aan staat heb je een probleem.

Je omzeilt dan helemaal niets, je creëert er een probleem bij. Namelijk dat SMART monitoring tools allemaal verkeerde informatie gaan tonen en je wellicht replacement cycles baseert op verkeerde data.

Dit probleem bij de oorzaak aanpakken en oplossen is ongeveer net zo makkelijk als een /24 doen in de code.

Maar dan zou je in principe de SSD elke 59 minuten laten restarten zodat het altijd op 0 blijft staan. Ook krijg je om deze reden geen accuraat beeld over het verbruik (10x 9 uur 59 minuten = 90 uur). Als het voor garantie gebruikt wordt, zou je in principe na 2 jaar een SSD kunnen terug sturen met 0 uur op de teller "want de SSD was uit doos al traag".

Dan is het power on count nummer heel hoog. Dus dan heb je 0 uren maar 32k power on events. Ook schrijf en lees tellers zullen gewoon omhoog gaan.

Dan ga je er standaard van uit dat het bij een restart op 0 gezet wordt en dat is dus niet het geval.

Hij bedoelt denk ik eerder dat z'n urenteller niet een tweede minuten of secondenteller heeft onthoudt waar in het uur je was toen de SSD werd herstart.

Minuten en seconden halen dat getal ook niet, het gaat hier enkel om de uren en dat deze als unsigned integer worden opgeslagen. Het opslaan van seconden en minuten als unsigned integer is geen enkel probleem.

Ik denk dat het kwartje nog niet gevallen is:

Iets in die SSD telt tot 1 uur. Daar gebruiken ze volatile storage voor (RAM dus), want als je elke minuut (of zelfs seconde) een teller daarvan moet opslaan in flash dan schrijf je duizenden keren per dag een teller en dus een heel block (want SSD) opnieuw weg, dat wil je niet om de wear niet te vergroten maar ook niet vanwege de peformance hit. Die volatile storage is een variabele in een programma of script, dus in wezen doet die zoiets als

int minuten = 0;
while(1){
sleep(60);
minuten++;
if (minuten == 60){
write_flash(read_flash(uren) + 1); //dit is een block write = wear
}
minuten = 0;
}

De werkelijke implementatie zal waarschijnlijk op een timer-interrupt zijn maar dat terzijde, het gaat erom dat er een waarde in RAM wordt opgeteld totdat die een drempel bereikt die een heel uur vertegenwoordigt, pas dan wordt de 'dure' write naar flash gedaan.

De suggestie van Memori is kloppend in de zin van dat als de SSD herstart wordt, de volatile storage leeg is en dus het tellertje in RAM weer op 0 staat en er dan weer een heel uur voorbij moet gaan voordat hij de uurteller in flash 1 ophoogt. Door dat dus elke 59 minuten te doen wordt de teller nooit opgehoogd en haal je (in theorie) nooit de 32768 van de signed integer (niet unsigned).

[Reactie gewijzigd door The Third Man op 27 november 2019 12:44]

Je kunt ook de tijd in ram onthouden en eens in de zoveel tijd naar flash wegschrijven.
Je kunt het in ram onthouden en op het moment van uitschakelen naar flash wegschrijven.
Het punt is dat je die uitspraak niet kunt doen zonder de implementatie te weten.
Er zijn meerdere mogelijkheden om hetzelfde resultaat te bereiken.
Misschien dat nu bij jou het kwartje valt, ik doe namelijk niets met kwartjes aangezien we in het euro tijdperk leven.

[Reactie gewijzigd door Galan op 27 november 2019 15:19]

Precies maar als het dus in je RAM zit dan ben je het kwijt bij een reset/restart, dat is Memori's punt. Het klopt ook dat we dat niet weten, maar dat is simpelweg wel te testen door dit een paar keer op een affected drive uit te rollen. Dus zo bot als je nu reageert hoef je nou ook weer niet te doen, want werkt het dan is het een workaround totdat je de firmware kan flashen.

Nee dat is dus niet per definitie zo.
Als het in ram bewaard wordt weet je nog steeds niet wanneer het wordt weggeschreven.
Je kunt er dus met geen mogelijkheid vanuit gaan dat het reset naar 0.
Lees ook zijn post even het is namelijk een reactie op zijn post waar mij hetzelfde wordt verteld.
Als je bot naar mij reageerd kun je een botte reactie terug verwachten.

...dan schrijf je duizenden keren per dag een teller en dus een heel block (want SSD) opnieuw weg

Dat hoeft niet. In flash-geheugen kun je iedere bit afzonderlijk van 1 naar 0 programmeren, alleen als je van 0 naar 1 wilt moet je een heel block wissen. Daarvan gebruik makend kun een algoritme bedenken dat in het flash-geheugen de verlopen seconden bijhoudt, zonder dat dat voor veel slijtage zorgt. Een simpele implementatie zou steeds ieder volgend bit op 0 zetten; stel dat je block size 512 bytes is, dan hoef je pas na ruim een uur het gebruikte block te wissen. Om de verlopen tijd op een dergelijke manier per minuut bij te houden zal al helemaal geen probleem zijn.

512 bytes? Dat is een page niet een block, die zijn doorgaans 64 kB of meer... En kan je linken hoe je een afzonderlijke bit van 1 naar 0 kan setten (programmeren is wat anders), want dat is geheel nieuw voor mij, ik weet niet beter dan dat je een erase kan doen op een block en dus voor data behoud alle pages moet terugschrijven.

Oké, ik ontwikkel op dit moment op een microcontroller waarvan het embedded flash veel kleinere blocks en pages heeft, maar dat doet aan het principe niet af. En met een block size van 64 kB kun je dus heel wat meer seconden vooruit voordat je dat een keer moet wissen...
Om een bit op 0 te programmeren, zet je in je RAM-kopie van de betreffende page dat bit op 0 en programmeer je de page zoals gebruikelijk. Dat heeft alleen effect op de bits die in het flashgeheugen op 1 stonden en in je buffer op 0.

Microcontrollers gebruiken NOR flash en daar speelt dat veel minder dan bij NAND, dus dit is dan sowieso een appel/peer vergelijking. Maar dan nog moet je een erase doen voor de write en dat raakt alle cellen in het block en dat zorgt voor de wear, terwijl bij EEPROM je enkel de cellen treft waar de bitjes daadwerkelijk flippen, wellicht heb je het daar vandaan. Het is daarom ook niet zo vreemd dat de specs van het flash geheugen ook een X-aantal erase/write cycles geven, dus ongeacht het aantal geflipte bits, terwijl als jouw verhaal zou kloppen de wear af zou hangen van de daadwerkelijke flippende bits.

Maar dan nog moet je een erase doen voor de write

Niet per se, maar na wat googelen kom ik tot de conclusie dat de waarheid in het midden ligt. Het klopt wel degelijk dat je bij flash ROM, zonder te wissen, een pagina meerdere keren kunt programmeren, mits er daarin alleen bits van 1 naar 0 veranderen. Maar ook is het zo dat verscheidene fabrikanten aanbevelen om dat liever niet te doen. Een mogelijke reden die iemand daarvoor oppert is dat ook cellen die zelf niet op 0 worden geprogrammeerd, via lekweerstanden toch wat lading kunnen meekrijgen van naastliggende cellen, wat er na een groot aantal keren voor zou kunnen zorgen dat ze de verkeerde waarde teruggeven.

Hoe dan ook is gebruik maken van een feature die door de fabrikant niet expliciet wordt gespecificeerd, of zelfs afgeraden, geen goede engineering practice.

Ja, het is best wel belangrijk, want door dit foutje gaan SSDs kapot. Ik ben enkel benieuwd naar de reden voor deze teller. Het lijkt mij namelijk niet relevant voor de functionaliteit van de schrijf, maar toch zorgt het ervoor dat de schijf niet meer werkt.

Je weet helemaal niet of bij deze SSD de urenteller op 0 blijft staan als je hem na iedere 59 minuten opnieuw opstart. Het kan best zo zijn dat deze de seconden en minuten ook in niet-volatiel geheugen bijhoudt, en dat de urenteller al 1 minuut na het weer opstarten op 1 wordt gezet.

En belangrijk is dat niet, want niemand gaat zijn SSD iedere 59 minuten opnieuw opstarten om dit probleem te vermijden. Dat is toch veel omslachtiger dan het probleem op te lossen met een firmware-update?

Die schijf zal ongetwijfeld gewoon kunnen werken zonder bij te houden hoe lang hij in totaal heeft gedraaid, maar sommige gebruikers zijn daarin geïnteresseerd. De firmware zal wel meer statistieken bijhouden die niet voor iedereen van belang zijn. Daar heb je ook totaal geen last van, tenzij er programmeerfouten in zijn gemaakt die zo ongelukkig uitpakken als in dit geval.

Er worden tientallen verschillende variabelen in een firmware bijgehouden die meer doen dan alleen maar de functionaliteiten waar wij weet van hebben. De reden om dit bij te houden kan niet ter discussie staan, dat is echt van een ander niveau. Neemt niet weg dat het kapot gaan van de schijven op deze manier een probleem is.

Als je kan voorkomen dat je SSD het in het geheel niet meer doet dan lijkt me dat wel belangrijk ja...

Als je kan voorkomen dat je SSD het in het geheel niet meer doet dan lijkt me dat wel belangrijk ja...

Je kunt dat voorkomen door de firmware van de SSD te updaten. Waarom is het belangrijk dat het ook veel moeilijker zou kunnen?

Natuurlijk, dat is ook de de echte oplossing. Maar het bediscussiëren van een workaround is niet daarmee onbelangrijk.

Dat iets niet geheel onbelangrijk is, betekent natuurlijk nog niet dat het belangrijk is.

"hoeveel uren de schijf heeft gedraaid"

Dan zou de teller altijd op nul blijven staan en was er geen probleem...

Planned obsolescence is not a bug, it's a feature, unless it's found out, then it's a bug.

Maar waarom gebruik je een signer integer voor het bijhouden bedrijfsuren? Zijn er ook schrijven met negatieve uren? Zo niet, waarom dan niet een unsigned (16-bit) integer?

Dan was het probleem pas na 7 jaar ontstaan bij de 27/4/365 gebruik, de meeste server systemen behalen niet die leeftijd.. Steeds meer bedrijven schrijven servers af over 4 of 5 jaar..

Zijn er ook schrijven met negatieve uren?

Ik neem aan van niet, zou vreemd zijn.

Zo niet, waarom dan niet een unsigned (16-bit) integer?

Waarschijnlijk een programmeur die niet volledig stil stond bij wat gedaan werd.

Dan was het probleem pas na 7 jaar ontstaan bij de 27/4/365 gebruik, de meeste server systemen behalen niet die leeftijd.. Steeds meer bedrijven schrijven servers af over 4 of 5 jaar..

Zelfs dan is het geen gewenste situatie, het liefst wil je iets hebben wat werkt ongeacht het aantal uren tot de SSD daadwerkelijk kapot is. Softwarefouten die hem sneller obsolete maken is een slechte zet.

Ongeveer zo soort situatie heb ik pas geleden ook gehad met Intel SDD's (Intel SSD D3-S4510 serie). Heel vervelend, waardoor we hoop tijd kwijt zijn geraakt aan het herstellen van data. Gelukkig hadden we genoeg en actuele backups op andere locaties staan.

NOTE: Intel has introduced the MR1 firmware for the Intel® SSD D3-S4510 and D3-S4610 Series 1.92TB and 3.84TB SKUs to prevent the NAND channel hang condition that can occur after approximately 1700 hours of cumulative power-on idle time with the older firmware XCV10100. The MR 1 firmware also offers additional product updates that affect all capacity drives. Intel strongly recommends all Intel® SSD D3-S4510 Series and Intel® SSD D3-S4610 Series SKUs upgrade to the MR1 firmware IMMEDIATELY.

https://downloadcenter.in...-S4510-S4610-2-5-material

[Reactie gewijzigd door Xieoxer op 27 november 2019 10:44]

1700 uur idle time? Dat is slechts net iets meer dan 70 dagen. Vreemd dat ze daar tijdens hun tests en QA niet tegenaan zijn gelopen

Dat is idle time, in de meeste computers zijn dat niet veel uurtjes en al helemaal niet op een test systeem

Ik weet niet wat er dan onder idle-time verstaan wordt, maar 100% non-stop bezig zijn ze bij ons toch echt niet hoor :-)

Nee maar 1700 uur idle time telt dan al snel op naar een stuk meer dan 70 dagen, en ik neem aan dat ze die dingen niet twee jaar lang duurtesten, tegen de tijd dat je klaar bent is het produkt verouderd.

Wordt voor een hoop mensen een nóg drukkere december maand. Het zal je maar gebeuren dat je deze melding hebt gemist en zowel je primaire, secundaire (failover) en backup hebben SSD's uit de betreffende series. Het doom scenario van iedere IT-er.

True, zou lullig zijn als je er tegenaan loopt.

Gelukkig is een firmware flash bij HPE altijd heel erg makkelijk door te voeren, en het probleem dus preventief op te lossen voor mensen er tegenaan lopen.

Is eigenlijk bekend wie de producent van deze SSD's is? HP produceert ze volgens mij niet zelf, toch?

Gelukkig is een firmware flash bij HPE altijd heel erg makkelijk door te voeren, en het probleem dus preventief op te lossen voor mensen er tegenaan lopen.

Is er een linux of macOS versie van de FW updater?

Voor MacOS weet ik het niet, maar voor Windows, Linux en VMWare ESX staan de firmware-flashers op de in het artikel aangegeven URL: https://support.hpe.com/h...cId=emr_na-a00092491en_us

Wel even goed opletten op welk model je moet hebben, gaat om 2 verschillende firmwares dus.

Zijn wel de online flashtools, of er een offline tool is (of dat die later komt) weet ik zo 1-2-3 even niet.

Weet niet of het voor allen geld maar ik heb 2 Samsung OEMs. Hoe dan komt het vaak voor bij HP dat ze custom firmware hebben voor hun HDD/SSD's.

Samsung en Intel.

Samsung, Intel, Micron en HGST zijn veruit de grootste SSD OEMs.

daarom is er de 3-2-1 backup strategy
3 verschillende backup sets
op 2 verschillende soorten media
waarvan 1 offsite

En waarvan 1 offline.

Dat is lang niet altijd meer een mogelijkheid. Zowel fysiek, doorlooptijd en wettelijk.

Veelal zie je onsite en versioning binnen 1 omgeving en offsite een replica. Replicatie werkt niet altijd tussen verschillende vendor's.

Dat staat hier, in mijn ogen, los van. Los van of je wel of niet een backup hebt kun je problemen krijgen met je SSD. Als dit al is voorgekomen voordat deze patch uitkwam ben je de zak en mag je dokken voor een nieuwe SSD terwijl het probleem door software kwam. En als je een mooie RAID array hebt staan met eenzelfde batch SSD's (wat enorm gangbaar is), dan zeg maar ook gedag tegen je andere SSD's voor/tijdens het rebuilden. Mag je inderdaad hopen dat je een (WERKENDE!) backup hebt, maar dat verandert niks aan de extra kosten.

En dan overal dezelfde SSD's hebben, omdat je ze in bulk gekocht hebt

Dit staat uiteraard los van backup, het gaat hier eerder over redundantie die om die reden onderuit wordt gehaald. Meerdere van deze schijven in RAID gaan dan tegelijk kapot gaan. Tenzij je "geluk" had dat er al eerder van deze SSD's kapot zijn gegaan door een andere reden en bijgevolg al vervangen zijn, dan zullen ze niet meer hetzelfde aantal draaiuren hebben.

Kans is klein dat je dit mist. HP heeft ons verwittigd en is reeds gepacthed. Suppliers volgen dit meestal goed op.

Zeker klein maar wij hebben hier heel wat HP spul staan (uit contract) en hebben de melding niet gehad. Het is dat ik regelmatig Op alle hardware (stuk of 30 servers en diverse storage) weliswaar 2 SSD's die mogelijk getroffen zijn. Het is dat ik regelmatig de CB's van HP lees anders had ik deze mogelijk veel later gezien.

True, maar dat is natuurlijk je eigen verantwoordelijkheid om op te volgen als je geen contract hebt met een supplier.

Als je je aanmeldt voor de driver / firmware notificaties krijg je die ook voor producten die niet in support zijn. Maar.... als je vertrouwd op spullen die niet in support zijn moet je ook niet zeuren over de support
Maar eerlijk is eerlijk, wij hebben ook niet alles in support (storage overigens wel). Maar we hebben dermate veel overcapaciteit en redundancy dat er een tank voorbij moet komen voor onze diensten uit de lucht zijn.

Denk meer aan test / ontwikkel omgevingen wat een doorschuif van productie is. Geen support maar vaak ook geen enkele reden om niet zo te gebruiken zolang je maar weet wat de consequenties zijn.

Zeker, doen wij ook. Maar het ging erover dat je geen support melding hebt gehad en dat is dus niet gek op niet supported hardware. Maar de notificaties hp waar je je op kan aanmelden werken wel heel goed.

Wij hebben overigens zelfs bepaalde productie servers niet in 4uur support, soms niet eens NBD buiten de eerste 3 jaar die je erbij krijgt. Buiten de overcapaciteit nemen we meestal gewoon een server extra van een bepaald type wat als spare in een rack komt. Daar hebben we bij een hardware crash veel sneller dan die 4 uur de server weer mee in de lucht, tegen een fractie van de prijs van die 4 uurs HPe support. Dus ik kan je gedachtengang zeker volgen

HPe heeft email notificatie welke je kunt aanzetten voor de apparatuur die je van ze hebt. Voor wat betreft de storage / SSD's in dit geval heb ik al meermaals een critical bulletin gehad. Niet te missen

Waar zet ik dat aan ;-)

https://connect.hpe.com/mypreferences/?language=EN. Die staat bij zowat elk product op Support Center (bv https://support.hpe.com/h...rt=relevancy&layout=table) onder 'sign up for alerts'. Daar email adres opgeven, linkje in je mail volgen en dan onder 'Support alerts' 'Manage your support alerts subscriptions'. Daar kan je van alle productgroepen en specifieke modellen notification aanzetten.

Heel erg bedankt, wist het bestaan hier niet van. Direct even voor alle producten die we in beheer/gebruik hebben aangezet!

Daarom (om common failure te voorkomen) gebruik je dus verschillende merk/type schijven.
Standaardisatie is niet de oplossing voor alles.

Buiten dat je de keuze vaak niet hebt (anders had er ook geen HP eigen firmware op hoeven staan), zijn er niet eens genoeg sas enterprise ssd's van dezelfde grootte van verschillende fabrikanten om een beetje storage systeem mee te vullen.

In sommige gevallen is dat in de benoemde HP hardware helemaal niet mogelijk.

Het zal je maar gebeuren dat je deze melding hebt gemist en zowel je primaire, secundaire (failover) en backup hebben SSD's uit de betreffende series. Het doom scenario van iedere IT-er.

Het is niet aangeraden om deze hele keten op precies identieke hardware te draaien.

Zoals verderop ook staat heb je niet altijd de keuze daarin.

Vraag me alleen af hoe een integer overflow ervoor kan zorgen dat je data corrupt raakt.
Een beetje programeur houdt hier toch rekening mee.
Of je nou 32 bit of 16 bits gebruikt een overflow mag nooit in een corrupt systeem veranderen lijkt me.
Wat wel sneu is is dat redunantie nu geen enkel nut heeft, omdat die in de zelfde minuut ook kapoet gaan.
Dan kun je dus beter je schijven met een tijdsintervallen aan je array toevoegen, of verschillinde types combineren

De data raakt niet corrupt, maar het plaatst de controller in een staat waardoor deze hangt.
De controller zorgt ook voor de mapping van logische blokken naar fysieke blokken, en bij veel van deze controllers wordt deze in de flash van de controller zelf opgeslagen.

Zonder deze data wordt het heel lastig om de data nog te restoren (door bijvoorbeeld de controller chip te vervangen).

Je data raakt niet corrupt, de firmware leest opeens "-32768 uur" aan draaitijd af waar het niet op berekend is. De firmware crasht daardoor, wat ervoor zorgt dat je niet bij je data komt. Dus de data is er nog, maar mag alsnog als verloren worden beschouwd.

Een beetje programeur houdt hier toch rekening mee.

Als dat zo was hadden we nu geen artikel om op te reageren.

Als dat zo was hadden we nu geen artikel om op te reageren.

Ik zie geen artikelen over andere fabrikanten, dus daar gaat het blijkbaar wel goed.

"Jij" ziet geen artikelen over andere fabrikanten. Dus bij andere fabrikanten gaat nooit wat mis....

Als je al zo lang in het storage wereldje zit, zoals ik, krijg je al jarenlang bulletins van EMC, NetApp, HP, DELL, IBM und und und und en bij alle zitten er af en toe berichten tussen over mogelijke "data loss". Dan patch je je systemen zoals beschreven in het bulletin en klaar. Niets aan de hand. Shit happens everywhere.

Ik hoop niet dat Tweakers je enige bron is voor zulke informatie met je "ik zie geen artikelen over andere fabrikanten".

De afwezigheid van bewijs is niet bewijs van afwezigheid. Bij andere fabrikanten zal dit specifiek misschien wel goed gaan, maar daar zijn ook genoeg dingen die iemand over het hoofd zal kunnen zien.

Ik zie geen artikelen over andere fabrikanten, dus daar gaat het blijkbaar wel goed.

Als Tweakers uw enige bron is voor dit soort info hoop ik dat u niet werkzaam bent als IT-er in storage.

Dus, met 32768 later uur, kun je weer bij je data =).

Het getal is dan weer boven nul, en bugt het niet. (in theory)

Was ook mijn eerste gedachte. kost je wel 3 jaar en wat maanden.

De urenteller wordt natuurlijk alleen bijgewerkt als de SSD in een operationele staat is, dat is niet meer het geval zodra de controller crasht op een negatieve waarde

het is wel heel naief om te denken dat 'n programmeur daar rekening mee houd.

Ik heb vaak genoeg mensen gesproken die niet eens weten dat er iets bestaat als overflow.
Daarom moeten mensen ook gewoon overal js voor gebruiken, dan krijg je tenminste Infinite+

Das niet naïef maar meer een ding uit eigen ervaring.
En net als madmarky al zegt js werkt niet op een microcontroller.
Een 32bit integer had inderdaad dit probleem moeten voorkomen, je weet tenslotte al in welke range je variabelen in dit geval urenteller moet zijn, dus om daar een 16b voor te gebruiken ...
Daarnaast gebruik je nooit voor variablelen welke niet negatief mogen worden een signed integer, dat is vragen om problemen.
Mocht er geen mogelijkheid zijn voor 32b kun je ook zeggen X=(X>0xFFFE) ? X-1 : X
Dat voorkomt een overflow naar zero.

Ik doelde er meer op dat je vrij vaak tegen personen aanloopt die van tieten nog blazen weten. Ik weet niet of dat anders is voor developers die iets dichter op de hardware zitten. Lijkt me inderdaad wel.

Dat van JS was uiteraard een grap.

Daarom moeten mensen ook gewoon overal js voor gebruiken, dan krijg je tenminste Infinite+

js gebruiken voor controller firmware, dat niemand daar eerder aan gedacht heeft

In dit soort gevallen moet een programmeur gewoon goed nadenken waar hij mee bezig is, net zoals een database designer van tevoren nadenkt over het soort data dat opgeslagen gaat worden in een veld van een table. Met een unsigned integer was de levensduur al dubbel zo lang geweest maar eigenlijk gebruik je voor dit soort 'infinite" tellers standaard een unsigned long (2^32 oftewel 4.294.967.295 uur in dit geval)

2^16... Oeps!
Programeer foutje bedankt

2^16... Oeps!
Programeer foutje bedankt

*Typefoutje ?

2^15 = 32768

Met een sign-bit (-32768 tot +32768)

<nerd mode>
-32768 tot +32767
</nerd mode>

[Reactie gewijzigd door Epsilon op 27 november 2019 10:26]

Wel interessant, klinkt als iets wat gebruiksuren telt of zo.
Die kan nooit negatief zijn

Maar als je de boel in bijvoorbeeld Java bakt, heb je gewoon altijd de negatieve optie. Of je het nou leuk vindt of niet. Of misschien is hier ergens een controle-bitje gebruikt, of is er maar 15 bits gereserveerd voor uptime, onder de logica dat 640k voor iedereen genoeg moet zijn...

In tegenstelling tot het gebruik van geheugen, is de lengte van een seconde exact bekend. Het zal wel een ongelukje zijn. Als het geen ongelukje is, zou het alleen maar planned obsolescence kunnen zijn.

Onderschat nooit de luiheid van een programmeur

Dat kan idd niet nee, maarja, als het getal als een signed int wordt opgeslagen, kun je roepen wat je wil, maar blijft 32768 het hoogst mogelijk getal dat erin past.

Unsigned opslaan zou het probleem alleen maar oprekken naar ~7 jaar.

[Reactie gewijzigd door _Thanatos_ op 27 november 2019 12:39]

Klopt, 2^15e met een signed bit. Maar dat is (neem ik aan) niet gelijk aan de notatie 2^16? Om verwarring te vermijden toch

Het is een 16 bits (unsigned) integer. Voor de sign hebben ze een bitje nodig, vandaar dat er 15 overblijven voor het representeren van een getal.

Succes met het vinden van een systeem waarbij ints zijn opgeslagen in een 15-bit getal. Het is nog steeds een 16-bit integer, maar dan signed waardoor 1 bit wordt gebruikt voor toewijzing van + of -.

Refererend naar de gevonden informatie is het gewoon 2^15 met een signed bit, en is 2^16 een foute notatie?

Dit soort firmware zal sterk geoptimaliseerd zijn om met zo min mogelijk verbruik te kunnen draaien.

Als je het teken niet gebruikt, zijn er dus effectief 15 bits om het getal in op te slaan. Je hoeft niet ver te zoeken naar zo'n systeem, je zit er waarschijnlijk achter als je dit leest.

Nee, geen typfout:

A 16-bit integer can store 216 (or 65,536) distinct values. In an unsigned representation, these values are the integers between 0 and 65,535; using two's complement, possible values range from −32,768 to 32,767.

De roll-over, die niet goed wordt opgevangen door de getroffen firmwares, is een 16-bit probleem.

Refererend naar de gevonden informatie is het gewoon 2^15 met een signed bit, en is 2^16 een foute notatie? Of ben ik mis?

Uit je eigen link de tweede zin gepakt:

It is notable in computer science for being the absolute value of the maximum negative value of a 16-bit signed integer.

Ja, de waarde zelf is gelijk aan 2^15. Helemaal gelijk in. Maar waar het om ging in het bericht van @Pep7777 was dat het kwam door een 16-bit integer. Goed, zonder deze kennis leest het natuurlijk raar.

Je zou maar zo'n hele rack aan storage hebben hangen die dus inclusief rack naar binnen is gereden.

Ja en? Dan update je de firmwares toch? Al je hardware dien je te onderhouden. Wij hebben een aantal van deze SSD's in gebruik, maar ik zie het probleem niet. Er komen (gelukkig!) regelmatig updates uit voor zowel de storage controllers zelf, alsook de schijven en ssd's. Niet alle problemen kunnen voorzien worden en gelukkig wordt het tijdig gemeld en is er gewoon een firmware beschikbaar. Afhankelijk van je storage controller kan je het zelfs live updaten.
De veelal Windows servers die ik op diezelfde storage draai, moet ik maandelijks patchen om problemen te voorkomen...

Dat gezegd hebbende, dit lijkt wel een heel knullige fout.

[Reactie gewijzigd door Rataplan_ op 27 november 2019 10:16]

Hij bedoelt dat HP er waarschijnlijk achter is gekomen doordat een klant dit heeft gemeld na het incident te hebben ervaren.

Wat betekend dat het voor die klant , of de eerste klanten best zuur is.

Stel dat je 50 exchange servers besteld had met als OS disk deze ssd`s dan ligt je hele exchange cluster plat. Leuk dat je HP support hebt maar HP weet nog van niks en komt er daarna pas achter en stuurd firmware uit om issues te voorkomen bij andere klanten maar in tussen tijd kun jij 50 servers gaan recoveren.

Die klant.... ondergetekende! Twee weken terug.
2 vdi servers met elk 6 schijven. Binnen een uur allebei uit de productie. Dat was de helft van mijn productie omgeving. Gelukkig hebben de andere 2 servers een andere configuratie.
En we beschikken nog over een uitwijklocatie waar een deel van de vdi omgeving draait.
Het duurde 4 werkdagen, met een weekend er tussen, voor dit probleem herkent werd.
HP kende dit probleem nog niet. De tweede dag bleek er ergens anders een zelfde probleem te zijn. Met dezelfde type schijven. Er zijn array controllers vervangen, backplanes, kabels. Zelf de batterij van de array controller. Deze gaf ook een error. Maar dit bleek los te staan van het primaire probleem.

Overigens zijn we erg goed geholpen door het callcenter van HPE. Soms is de oorzaak van een probleem ook lastig te vinden.
Maar dat HPE was geïnformeerd door de manufacturer.........

exact, zo bedoelde ik het ;-) Ze komen er inderdaad niet zomaar achter denk ik of het moet een oplettende programmeur zijn.3 jaar is niet zo'n rare tijd om ze te hebben draaien.

Nee, HP is er blijkbaar achter gekomen door een waarschuwing van een van hun SSD fabrikanten. Uit de link die in het artikel staat:

"HPE was notified by a Solid State Drive (SSD) manufacturer of a firmware defect affecting certain SAS SSD models (reference the table below) used in a number of HPE server and storage products (i.e., HPE ProLiant, Synergy, Apollo, JBOD D3xxx, D6xxx, D8xxx, MSA, StoreVirtual 4335 and StoreVirtual 3200 are affected)."

Dat heet damage control,
Daar hoeft niets van waar te zijn (meestal)

Zie bovenstaand weldegelijk klanten impact dus ook zeer waarschijnlijk de trigger.

Misschien niet eens één klant, maar een aantal. Eén is een incident, 5 klanten is een problem.

Als er 1 klant is met x-aantal ssd hebben van dezelfde type die er allemaal uit knallen dan zou ik als HP al achter me oren krabben en controleren wat er precies aan de hand is om een aantal zaken uit te sluiten.

In dit geval maakte de leverancier een melding volgens HP. Alleen wordt vervolgens niet gemeld wie dat is. De kans dat ze custom-made SSD leveren geloof ik niet echt,
hooguit een aangepaste firmware. En zat in de aangepaste versie dan een vergissing of het origineel.

Tsja. Ik zou, als IT'er, eerst denken aan een backplane of de enclosure zelf of iets dergelijks, voordat ik aan firmwares van de SSD's zou denken.

Ligt er natuurlijk aan wat voor klant je bent, wat de impact is en wat je support bij HPE betreft denk ik.

Ja maar ik veronderstel (aanname) dat de daadwerkelijke fabrikant van de ssd (Seagate / Samsung enz) met name hun Enterprise ssd's wel ergens in een testbench laten draaien. Zelfde voor HP zelf. M.a.w. vermoed ik toch dat een van hen er eerder tegenaan loopt dan een klant, aangezien zo'n SSD eerst al lange tijd getest wordt voordat ze op de markt verschijnen.

Ik heb nergens gelezen dat klanten daadwerkelijk gedupeerd zijn hierdoor. En voor de rest blijft mijn insteek dat je als je zelf hardware in beheer hebt die ook actief moet beheren

In de tekst staat gewoon dat de leverancier HP hiervan op de hoogte heeft gebracht.

Ik vind dit eigenlijk een dermate kwalijk probleem, en zó knullig, dat HP de updates onsite mag komen uitvoeren. Waarom moet je als duur betalende klant hier tijd (=geld) in gaan steken terwijl het je fout niet is?

Een gewone firmware update, voor performance-verbeteringen of whatever, dat is natuurlijk iets heel anders. Dat is een update waar je zelf voor kan kiezen.

[Reactie gewijzigd door _Thanatos_ op 27 november 2019 12:43]

Ik vind dit eigenlijk een dermate kwalijk probleem, en zó knullig, dat HP de updates onsite mag komen uitvoeren.

Laat je even weten hoe HP daarop gereageerd heeft? Hoeveel van die drives heb je draaien?

Ik begrijp jouw opmerking gewoon echt niet. Als Microsoft een patch voor een kritiek probleem (bv Bluekeep) uitbrengt, bel je dan ook Microsoft op dat zij jouw systemen maar moeten komen patchen? En als Intel een microcode patch voor de zoveelste Spectre / Meltdown variant uitbrengt komt Intel jouw biossen allemaal flashen?

Wat mij betreft is dit niets anders. Er is een kritiek (en een domme, dat toegegeven) fout ontdekt in de firmware van één van de componenten van een systeem. Prima toch dat er patches voor beschikbaar zijn en komen? Ik zie echt het probleem niet. Je kunt simpelweg niet verwachten dat je storage, of dat nou HPe, Nimble, Netapp of wat hebben we allemaal aanschaft, dat alle componenten in zo'n systeem 100% bug vrij zijn. Onmogelijk.

[Reactie gewijzigd door Rataplan_ op 27 november 2019 14:05]

Nee. Maar het levert wel extra werk op wat niet te declareren valt. En een server kun je niet altijd makkelijk herstarten.

Nee maar dan stel ik nòg eens: kan jij je MS (en trouwens *nix hetzelfde) patching wél declareren bij je klant of je baas? Zo ja, dan moet je zorgen dat hardware patching OOK declarabel wordt als je een probleem hebt met de uren, want that's part of the business. Je diensten / servers m.a.w. software draaien op hardware, en die moet onderhouden worden. Declarabel of niet. Je kan niet verwachten dat een stuk hardware 100% foutvrij is.
In mijn beide SAN's zijn de disken overigens gewoon live te update, zonder downtime, als je er niet teveel tegelijk doet althans. Windows patchen kost ons echt een hoop meer ellende dan hardware updates in de regel...

[Reactie gewijzigd door Rataplan_ op 27 november 2019 15:03]

Nou, dat ben ik niet met je eens.
Dit is een fout van een heeeel andere orde dan de 'Spectre / Meltdown' problemen.
Dit is gewoon een oerstomme fout, die gewoon niet voor had mogen komen.
Zulke kritische code had gewoon beter nagekeken moeten worden.

En ik begrijp het nut van de bovenstaande discussies over hoe je dit op had kunnen lossen niet zo. Dit is gewoon een hele simpele bug die vast ook heel simpel op te lossen is. B.v. door een 64 bit variabele te gebruiken. Het probleem is niet hoe je dit op zou kunnen lossen, maar dat deze bug over het hoofd gezien is.

Firmware update kan gewoon remote, aantallen en positie maken dus niet zoveel uit. Blijft natuurlijk wel een zeer kritisch punt waar snel actie op ondernomen moet worden door een beheerder.

Ja maar ik bedoel dus dat dit geconstateerd wordt nadat je het zelf meemaakt, niet nu je nog actie kan ondernemen ;-)

Om vervolgens ook je redundantie met het zelfde systeem te hebben uitgevoerd. zodat die ook na 32768 uur stuk gaat

Volgens mij gaan ze al eerder stuk. Namelijk op 32768 uur en niet na 32768 uur. Ja, na 32768 uur zijn ze ook stuk, maar het gebeurt dus al eerder. Na 32767 uur zijn ze stuk.

Semantiek blijft een prachtig iets.

Net als wanneer mensen zeggen "ik ben de enigste persoon die dit voor elkaar kreeg". Nou ja, als je de enige bent ben je ook automatisch de enigste he

Veel voorkomende denkfout Als je geboren wordt ben je niet meteen 1 jaar. Een uur gebruik is dus ook pas na dat uur en niet aan 't begin ervan. De huidige eeuw begon ook pas op 1/1/2001.

De fout is heus niet het gebruik van een signed ipv een unsigned. Als dat zo was dan zouden de schijven onbruikbaar worden na een twee keer zo lange tijd. Is ook niet de bedoeling. De fix zit m eerder in de afhandeling bij een roll-over.

"Bovendien is de kans volgens HPE groot dat andere ssd's, die gelijktijdig met de getroffen ssd geïnstalleerd zijn, ook stuk gaan"

Zit je dan met je RAID configuratie...haha.

Belangrijk detail:

HPE zegt dat het door een ssd-leverancier op de hoogte is gesteld van het probleem.

De fout is niet door HPE veroorzaakt maar door de partij die de SSD's maakt voor HPE. Er is dus een kans dat er meerdere partijen zijn die last hebben van hetzelfde probleem maar dit nog niet gepubliceerd hebben.

Voor de mensen die niet direct weten hoe je dat kan checken:

Login op je ILO:
- ga naar information
- ga naar system information
- selecteer in je navigatiebalk rechtsboven STORAGE

Physical Drive in Port 1I Box 3 Bay 4
Status OK
Serial Number
Model
Media Type SSD
Capacity 480 GB
Location Port 1I Box 3 Bay 4
Firmware Version
Drive Configuration Configured
Encryption Status Not Encrypted

Je hoeft dus niet je server uit te zetten en je disken eruit te halen...