Některé SSD disky od HPE přestanou po 32 768 hodinách provozu fungovat (diskuse)

[Conscript89]

Podle oznameni jde o SAS disky. NVMe tam nevidim tak snad u tech to problem nebude, jinak budu muset kontaktovat nase labadminy :)

[Peter Golis]

HPE All Flash Storage, 100% availability just got faster.

[xkucf03]

Asi do oddělení disků nabrali někoho, kdo dělal dřív tonery do tiskáren, které mají taky po nějaké době přestat fungovat.

[Gréta]

:D si bych na to klidně vsadila:D :D :D

32767 je max hodnota signed int16 :D :D :D :D

[Radovan]

Třeba ten firmware prgali v Turbo Pascalu

[R]

HP disky nerobi, ale objednava si ich u vyrobcov (v tomto pripade asi Samsung?) s upravenym firmwarom. Ak to neposrali v HP pri uprave firmwaru, tak tento bug mozeme ocakavat aj u inych znaciek.

[dustin]

Dobrá otázka, kdo skutečně ten firmware do HP-brandovaných disků píše. V každém případě pokud by se neozval, tak by mohl čekat pěkné soudní tahanice, i kdyby už ty disky byly po záruce.

[j]

HP ten firmware zcela jiste nedela, upravy spocivaji prevazne v tom, ze se vypnou vsemozny "zrychlovaci" ficury, aby to melo pod kontrolou prave to pole. A protoze sas se typicky nevypina a typicky se HW pouziva 5 let, tak budou mit problem uplne vsichni. A zcela jiste predevsim ti vetsi budou pozadovat $$$, protoze upgrade firmware = nutnost odstavky = ztraty.

Takze jestli je v tom takovejhle bug, tak se zarucene projevi u vsech vyrobku danyho vyrobce. Jen v soho segmentu to bude trebas po 10+ letech.

[honk]

[Max]

Běží-li u vás HPE server již 3 roky a 270 dnů, tak máte 8 hodin na aktualizaci firmwaru.

To je super hláška :D
Zdar Max

[Odin1918]

Ano. Hagara v posledni dobe prekvapuje zajimavymi zpravickami.

[Blaazen]

Ale je to jen tak tak. Ono to totiž vychází, že disk by musel jet od 1.3.2016, jenže 2016 byl přestupný rok.

[Odin]

No a, na to rok nemá vliv. Pokud tam je přestupný den navíc, tak 1 rok po 15. červnu XXXX je 14. červen XXXX+1.

[Blaazen]

To bylo myšleno tak: od 1.3.2016 je to do 26.11.2019 3*365+270 = 1365 dní (32760 hodin)
Jenže o den dřív by to bylo 366+2*365+270 = 1366 dní (32784 hodin) => doba na upgrade prošvihnuta.
Ale je to jedno, protože autor zprávičky určitě na výpočet použil (jako já) nějakou utilitu, co s přestupnými roky počítá.

[Bedňa]

Občas je lepčie začať na čistej lúke a robiť veci lepšie, teraz to prišlo

[Thunder.m]

Apríl už letos byl...

[biolog]

3 roky provozu -- no jo, ale myslí se tím doba od zapnutí napájení do vypnutí, nebo doba "kolik mají odkrouceno"?

[dustin]

Jaký je v tom rozdíl? Standardní údaj Power-On Hours ve Smartu, jak píše HPE ve své zprávě.

[ed]

To je snad u servera skoro to iste, nie?

[/dev/urandom]

V HPE dokurvili kurvítko...

[MMMMMMMMM]

Přesně to mne napadlo.

[Lokomotiva]

Pozastavil se vůbec někdo nad tím, proč by měl být v enterprise SSD discích čítač času, po jehož vypršení dojde k destrukci všech uložených dat ve flash chipech ? Samotná existence takového nástroje je na žalobu.

"The issue affects SSDs with an HPE firmware version prior to HPD8 that results in SSD failure at 32,768 hours of operation (i.e., 3 years, 270 days 8 hours). After the SSD failure occurs, neither the SSD nor the data can be recovered. In addition, SSDs which were put into service at the same time will likely fail nearly simultaneously."

[Gilhad]

Citac casu muze byt soucasti statistik disku, stejne jako treba pocet vadnych sektoru. Ale pokud je blbe osetreny a blbe umisteny, tak pri preteceni muze napriklad modifikovat vedlejsi misto v pameti, kde je neco duleziteho (treba ukazatel nekam) a problem je na svete - data sice nejsou fyzicky prepsana, ale z nejakeho duvodu se hledaji jinde/interpretuji jinak a neni cesta, jak opravit to blbe prepsane misto, protoze nikdo necekal, ze by se melo nastavovat zvenku.

Windows takhle sveho casu padaly, kdyz je clovek nechal bezet moc dlouho a pretekl jim nejaky interni citac casu.

[Bedňa]

32768

[Lokomotiva]

No shit Sherlock. Jasně že to je součást statistik disku - SMARTu. Ale proč to po vypršení vymaže VŠECHNY UŽIVATELSKÁ DATA ? Tedy něco jako secure erase / mass erase. Aby to nebylo záměrné, tak by to musela být fakt hodně blbá chyba. Za normálních okolností by tak maximálně spadl firmware, a nešel nastartovat (takže by to šlo opravit nahozením bootloaderu např. a nastartováním firmware). Nebo by se zmrvil firmware, ale data by ve flash čipech byla dál, takže by z toho šly data dostat. Já jsem se pozastavil hlavně nad větou "After the SSD failure occurs, neither the SSD nor the data can be recovered".

A nutně to vede k otázce, jestli je výmaz nebo znefunkčnění VŠECH dat (netriviální operace) opravdu zcela náhodné chování při přetečení.

[Gilhad]

Nevim, ten firmware jsem samozrejme nevidel, natoz zkoumal.

Jen mam tu zkusenost, ze se obcas zadari tak neuveritelne chyby, ze by tomu clovek neveril, kdyby to na vlastnim stroji nedebugoval.

Takze samozrejme muze jit o konspiraci a udela to poctive vymaz vsech dat, nebo muze jit o nejakou kravinu, ktera nekde neco rozbordeli natolik, ze si vyrobce nelajsne rict, ze to dokaze snadno dat dohromady, natoz na to udelat jednoduchou klikaci utilitu, a tak radsi vyda prohlaseni, ze to vsechno pujde do kopru (a pak to mozna zkusi nejak ofixovat aspon tam, kde to pujde snadno), nez aby rekl, ze to pujde opravit a ono to pak nekde neslo.

Jak znamo, jedna blba carka sundala kosmickou sondu, me se zase podarilo udelat program, co pri demonstracich chodil skvele a pak v realnem provozu kvuli jednomu blbemu pretypovani si nahodne mazal data a delal jine neplechy. A nejhorsi na tom bylo, ze to delal z vnejsiho pohledu v podstate nahodne, nepredvidatelne a zridka, pricemz ty dusledky byly pokazde jine.

Takze je taky mozne, ze nejde o secure erase, ale o nahodne poskozeni neceho, co muze mit jako jeden z dusledku poskozenim vnitrnich tabulek, takze data tam jsou, jen k nim chybi indexy (a tudiz jako by nebyly), nebo ze si nejak nakope, co je alokovane, co volne a pak klidne jeste nejakou dobu pise do alokovanych veci v domeni, ze jde o volne misto - a vzhledem jak sibujou s wear leveling, tak pokud misto do dat pise do tech prealokavacich tabulek, tak vysledek klidne muze byt, ze data na disku "vicemene" jsou, jen se netusi kde a ktera - takze se to neda rozumne obnovit, ale zaroven to neni secure erased.

[xxx]

Tak jestli to v okamziku kdy ten citac je roven 0 smaze tabulku s mapovanim bloku (takovej fresh start), tak good luck se zachranou cehokoliv.

[dustin]

To zní docela pravděpodobně.

[j]

Nikde prece neni receno, ze to neco prepise, jen, ze ty data nebudou dostupny.

V principu to muze jit i primitivne trivialne opravit, jenze to je proste neco, co si nemuzes dovolit delat u stovek tisic zakazniku a na milionech kusech HW. Trebas to SSDcko proste na preteceni reaguje jen tak, ze prestane komunikovat, protoze konci na tom, ze neni jak dal navysit citac = defakto se vubec nic nedeje, jen ti prave prestalo fungovat diskovy pole = zastavila se firma, ktery prave generujes skody klidne v milionech eur kazdou minutu.

Popremejslej pak nad tim, co se asi tak stane se vsemmoznejma databazema, kdyz jim behem provozu jen tak znicehoz nic odpojis uloziste.

A dal, uvedom si, ze neco jinyho je resit jeden disk, u kteryho defakto znas organizaci dat na nem, a resit pole, ktery data rozhazuje pres desitky ale i tisice disku, takze kazdej kousek dat je jinde, a to vse jeste v zavislosti na spouste dalsich vecech, takze muzes mit klidne cast souboru na zapisovacich SSD, cast na ctecich, cast na 15k disku, dalsi kousek na 10k disku ... a zbytek na 7k disku, proste proto, ze se pole takhle rozhodlo podle toho jaka cast se casto prespisuje, jaka se casto cte a jaka se necte skoro vubec. Navic si pole muze klidne i samo algoritmicky urcovat, co bude jako R5, co jako R10 atd atd.

Neni na svete nikdo, kdo by ti tohle chtel davat dokupy, a i kdyby chtel, vyslo by te to o nekolik radu draz, nez kompletni obnova zaloh.