Vlákno názorů k článku
HPE vydává opravu na SAS SSD, přestaly by po 32k hodinách fungovat od Ondra Satai Nekola - To musí být super mít v RAIDu disky,...

Tak si pojďmě udělat test kritického myšlení. Zdrojové kódy firmwaru nemáme, tudíž vše zde nutně musí být do určité míry spekulace, pokud někdo neudělá reverse engineering toho firmwaru, ten jsem rozhodně neudělal a pochybuji, že ho udělal někdo z diskutujících.

Když máme jasno o čem se bavíme tak pojďme dál.

Máme disk SAS SSD - určení enterprise segment, tudíž nejvýnosnější část pro HP. HP by mělo mít nastavené procesy, aby takové scénáře měli být otestovány. Evidentně jim to, což moc důvěry v jejich procesy nedává, nejspíše už je vývoj dávno přeneseny za levnější pracovní silou. Dobrá, může se stát i když by se tedy rozhodně stávat nemělo.

Co přesně má firmware obsahovat? Má řídit a obsluhovat disk. Jaká funkcionalita může být tedy ve firmwaru obsažena, která za přesně daný čas ho znehodnotí a to tak, že data nelze obnovit? To znamená, že obsah všech buňěk je nejspíše přepsán nebo smazán a to nejspíše vícekrát. Jediná funkcionalita, která mě napadá, že by tohle mohla je nějaké bezpečné smazání, ale to není časově vázané. Nicméně takový firmware jsem ještě neviděl, což nevylučuje jeho existenci. Nicméně je to zvláštní.

Dále co mě zaráží, je to číslo samotné. Ta hodnota je přesně 2^15, což je hodnota `short int` v Cčku, v čem předpokládám, že ten firmware je napsaný. Fix tedy bude spočívat v tom, že tam dají `long long int`? A až pak ten disk bude k ničemu?

Tipnul bych si, že to přetečení způsobí zaseknutí firmwaru při startu disku. Zásek takový, že pak nejde ani přeflešnout nový firmware (standardní cestou).

Pochybuji, že by to prošlo všechny buňky a smazalo je to. Třeba je jenom velice komplikované ten nefunkční firmware bez poškození uložených dat opravit (např. je uložený ve stejných fleškách jako data) a pro HPE je jednodušší data prohlásit za finálně nedostupná, než se s tím mořit.

Celé HP (všechny dcery) jde docela rychle do háje. Stačí jejich geniální instalátor hplip https://sourceforge.net/p/hplip/news/2019/05/hplip-3195-release-notes/#1433 . Před chvílí jsem měl opět tu radost s nejnovější verzí, žádná změna.

> Tipnul bych si, že to přetečení způsobí zaseknutí firmwaru při startu disku. Zásek takový, že pak nejde ani přeflešnout > nový firmware (standardní cestou).

To se mě úplně nezdá, protože ta chyba je formulována:

"Neglecting to update to SSD Firmware Version HPD8 will result in drive failure and data loss at 32,768 hours of operation and require"

Jak to chápu je to tak, že se ten disk zasekne vždy po 32768 hodinách v provozu. T.j. budu mít disky v poli co poběží neustále a v tom běhu se zaseknou.

Mě přijde, že to přetečení přijde při sledování hodnoty "Power On Hours" nebo jiného běh sledujícího parametru. Nějak mě utíká souvislost, proč by tohle mělo znepřístupnit ten disk a celý ho poslat do věčných lovišť.

A asi ano bude jednodušší přinutit zákazníky rychle aktualizovat než-li to opravovat na vlastní náklady.

27. 11. 2019, 13:25 editováno autorem komentáře

Třeba jsou data šifrována a Power On Hours nějakým způsobem vstupuje do výpočtu nějakého klíče. Po přetečení se odvodí špatný klíč a začne to přepisovat data bordelem.

Třeba může jít o nějaký sanity check při startu. Nebo nějaká kontrola „stočení tachometru“.

No, i kdyby tam dali „jen“ 32b int se znaménkem, bude to 2^16 krát víc než dnes. Tedy cca 200 000 let. Něco mi říká, že do té doby se spolehlivě rozbije něco jiného.

Ta funkcionalita je "vydelat na supportu" jenze tady to trosku pokakali, nenazranost se nevyplaci. Nebo mi chces tvrdit ze nekdo kdo programuje firmware disku je takovy "trololo" ze na kritickou var da 16 bitu ?

Ano, vůbec by mne to nepřekvapilo. Zejména pokud to byla původně nějaká nepodstatná metrika, která se až časem dostala na nějakou kritickou cestu. Nebo to ani není samostatná proměnná, o které by někdo moc přemýšlel, a jen mezivýsledek s nešťastným typem.

Bohužel není uplně zřejmé, na co reagujete, možná na můj příspěvek o kontrole „stočení tachometru“.

Jestli to je výpočet z jiných dat – možná, ale moc mě nenapadá, z čeho by to šlo spočítat. Leda z času používání v jiných jednotkách. Pak by ale asi musel někdo ten typ explicitně přetypovat, jinak si to neumím moc představit.

Taky je otázka, jak to počítadlo hodin funguje – doba zapnutí přece není v celých hodinách. Zaokrouhluje se to? (Čekal bych zaokrouhlení nahoru – při načaté hodině se inkrementuje čítač.) Jak se řeší přepis této části paměti – přecejen zapisovat každou hodinu na stejné místo není zrovna šetrné… Uplatní se standardní wear leveling (hotový, ale pro danou situaci nepříliš efektivní), nebo nějaké řešení na míru situaci (možná hotové kvůli HDD*)

V neposlední řadě je otázka, jestli se ten znaménkový bit nepoužíval k nějakému účelu.

*) Popravdě nevím, kam ukládají HDD data ze SMARTu – jestl na plotny, nebo do nějaké flash paměti. Pokud do flash paměti, pak se nabízí přepoužití tohoto řešení i na SSD.

> Popravdě nevím, kam ukládají HDD data ze SMARTu

Starší disky ukládaly do EEPROM jejich MCU, ale moderní MCU epromku už většinou nemají. EEPROM je prostorově o dost náročnější než flash, dá se pomocí flashe emulovat, a tak s rostoucím tlakem na cenu jde pryč, protože zbytečně zvětšuje křemík. MCU se dělají o dost většími procesy (100-200 nm) než multimediální SoC.

Jsou to SLC flashe s ECC, výrobci garantují naprosto nesmyslné počty přepisů (a díky velikosti tranzistoru toho dosáhnou), takže inkrementace hodinového čítače to jen tak neoddělá :)

Nikdy se to ale nedává přímo na médium, to by pak SMART byl na dvě věci, když by třeba po selhání mechaniky nešel vyčíst.

Nějak jsem pocitově tušil, že to bude mimo médium, ale až tak samozřejmé mi to nepřijde. SMART potřebuju hlavně u zatím ještě (aspoň částečně) funkčních médií, aby mě varoval před blížící se smrtí. Nějaká port mortem analýza může být taky zajímavá, ale nevím, jak moc to média reálně umožňují.

Nemusí umřít, stačí, že by se ztratil např. sektor s údajem o počtu realokovaných sektorů :-) a nebo rovnou jejich seznam.

> stačí, že by se ztratil např. sektor s údajem o počtu realokovaných sektorů :-)

No, v této chvíli už víte, že máte problém…

> a nebo rovnou jejich seznam.

OK, to už je horší. Myslel jsem, že toto SSDčka řeší přímo na úložišti pomocí nějakých chytrých algoritmů (více kopií dat + nějaký wear leveling) a nevěděl jsem přesně jak. Pokud na to mají kvalitnější (ale asi dražší) paměť, celé se to zjednodušuje.

Netušíme, jak vlastně vypadá ten vývojový proces. Po tom, co vyplulo na povrch u Boeingu, by mě nějaký outsource vůbec nepřekvapil... Jak jsem psal výše o tom instalátoru driveru HP - z toho čiší výtvor nějakého začátečníka, který prostě dostal rámcové zadání, vůbec neznal (a tedy neřešil) souvislosti a nikdo zkušenější to po něm nezkontroloval. Vůbec bych se nedivil, kdyby podobný postup proběhl i u toho firmwaru.

Tak určitě. A ta ztráta dat na disku i celém RAIDu je bonus.

27. 11. 2019, 09:39 editováno autorem komentáře

To by byla hezká teorie. Kdyby ta chyba nezpůsobovala i nedostupnost dat...

Aha.

> Jev je současně provázen ztrátou dat na dané jednotce.

To je naozaj problém, a kto vymaže a nie len prestane komunikovať radič.

Tak on by jenom nekomunikující řadič určitě nebyl problém. A určitě by to HPE nestálo kopec peněz.