co dělají disky při chybě

11.12.2006 15:00 | Přečteno: 1874×

Schválně, zkusím si napsat, co dělají disky, když se nezadaří čtení nebo zápis. Uvidíme co z toho vyleze. Nic jsem o té věci soustavně nečet a ani nevím, jaká literatura by na to byla. Všechny informace mám z kusých zpráv obsažených v dokumentaci k programům a HW komponentám, a z vypravování techniků některých firem, které prodávají storage systémy. Některých, to znamená že někde nevědí nic, ale většinou spíš vědí.

Data na disku jsou uložena v takových kouscích, kterým se říká sektory. Sektor je z hlediska práce disku nejmenší částice dat, kterou lze najednou přečíst nebo zapsat. Velikost sektoru bývá 512B, nevím nakolik je to povinné. Sektory jsou uloženy za sebou v řádkách, kterým se říká stopy. Stopy jsou uloženy na cylindru. Disk obsahuje spoustu datových cylindrů a ještě jeden nebo dva cylindry náhradní.

Na magnetické ploše může být defekt, takže data do sektoru někdy nejde zapsat. V tom případě disk nikomu nic neřekne, vadný sektor si připíše na seznam defektů, a na stejné logické místo si zařadí jeden sektor z náhradní oblasti - z těch dvou neveřejných cylindrů. Kdyby ovšem náhradní sektory došly, potom by disk musel s pravdou ven a pěkně ohlásit chybu zápisu, a operační systém by se o problému dozvěděl. Jinak neví nic. Každý disk má defekty, to nic neznamená.

Horší situace nastane, když defekt vznikne až časem. Sektor třeba obsahuje data a najednou nejde přečíst. To potom disk zkouší čtení vícekrát a ještě při tom všelijak nakrucuje čtecí hlavu, jestli by se to náhodou nechytlo. Když ne, disk nahlási neopravitelnou chybu a dál je to na OS. Ale i kdyby se čtení nakonec povedlo, disk by měl určitě právě pracně přečtená data uložit zase na náhradní sektor a vadný sektor si vyřadit.

Některé disky mají v sobě inteligentní subsystém zvaný S.M.A.R.T. Ten si udržuje statistiku o počtu realokovaných sektorů a vůbec o chybách za provozu. S.M.A.R.T. statistiky jsou uživatelsky přístupné klidně i za provozu. V linuxu je na to program smartctl. Jednou jsem se díval, jak se bootuje jeden systém po závadě zdánlivě bezvadně spravený, a vidím na konzole najednou nápis: Drive .... is predicting future failure. To dělá taky ten S.M.A.R.T. když se mu zdá, že už je těch chyb nějak moc. Říkal jsem že je inteligentní, ne? Výskyt tohohle hlášení by měl výrobce uznat jako důvod k reklamaci.

Můžeme se podívat na web výrobce disků, a najdeme tam diagnostické programy, které umožňují testování, třeba i nějaké nasetování, a taky prohlédnutí S.M.A.R.T. statistik. I levné disky dneska slavnostně podporují S.M.A.R.T. Ale potom si tam člověk třeba pustí analýzu povrchu, načež se mu před očima S.M.A.R.T. statistika vynuluje. Čili ještě i na konci roku 2006 bych spíš řekl, že S.M.A.R.T. je výsadou disků vyšší třídy.

Já vím že už je to dlouhý, ale ještě musím ztratit slovo o diskových polích. Jestliže jsou disky připojeny k RAID řadiči, potom tento řadič je pro ně to, čemu jsem až do teďka říkal "OS". Řadič diskového pole nemusí mít žádné speciální rutiny pro disky nějakého výrobce nebo typu. Jaké disky k němu připojíme, je aspoň do určité míry jedno. Jestliže disk ohlásí chybu čtení, pole si chybějící data zrekonstruuje z dat na ostatních discích a nahoru - tentokrát snad už opravdu do OS - pošle správná data. Ale současně by mělo chybující disk označit jako vadný a začít výstražně pištět. Toto musí dělat každé diskové pole hodné toho jména. Jiná věc je, že potom třeba přijde technik od servisu toho pole a se slovy Jo to se stává ten dotyčný disk vytáhne a zase zastrčí.

Říká se, že když v diskovém poli odejde disk, tak vždycky víc najednou. Osobně jsem to nezažil, ale proč ne. Po odpojení disku a po automatickém připojení hot spare nastane rekonstrukce paritních informací, to znamená přečíst úplně všecko ze všech zbývajícíhc disků v poli. To se potom nedivte, že se při tom projeví další defekty. Snad by se to nemuselo stávat na polích střední a vysoké třídy. Tahle pole mají umět preventivní vyhledávání vadných disků. Mají na to dva nástroje - jednak pravidelně prohlížejí S.M.A.R.T. statistiky, jednak je možné nakonfigurovat pravidelné analýzy povrchu za provozu.

Disková pole střední a vysoké třídy jsem zatím viděl jenom na obrázku, takže mám příležitost tenhle přízpěv ukončit. Howgh.

       

Komentáře

[David Ježek]

SMARJA :-O

[wake]

snad

S.M.A.R.(T).J.A.

, ne?

[Messa]

Když mi odcházel disk na mém PC (low-end, nic extra), tak byl počítač spíše nepoužitelný. Nešlo přečíst jen některé pro OS nedůležité soubory, ale když se je při pokusu o zálohu systém pokusil přečíst, tak se třeba na minutu zasekl. U diskových polí (HW i SW), kde jsou závady celkem časté, je to jistě nějak ošetřeno, že? (Asi by nebylo vhodné minutu zdržovat, jestli se disk nekonec neumoudří.)

[krnoha]

To já fakt nevím, co dělá linux když něco nemůže přečíst. Že by posílal požadavek disku pořád dokola? Nebo že by disku opravdu tak dlouho trvalo, než to skutečně vzdá? Pole samozřejmě nemá důvod čekat, dávno si data dopočítá o odešle.

[XMurder]

Můj Seagate (ST310212A, 10.2GB, UATA, rok výroby 2000) má už docela dost "naběháno" a stále je v dobré kondici, i po několika desítkách výpadků proudu (naopak jeden IBM 30GB na výpadky hrozně trpí a dlouho už nevydrží, proto preferuji Seagate). Stále kontroluji S.M.R.A.T, zde je výpis pro ilustraci:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0008   083   082   000    Old_age   Offline      -       115001966
  3 Spin_Up_Time            0x0006   098   098   000    Old_age   Always       -       0
  4 Start_Stop_Count        0x0013   098   098   020    Pre-fail  Always       -       2370
  5 Reallocated_Sector_Ct   0x0013   100   100   036    Pre-fail  Always       -       23
  7 Seek_Error_Rate         0x0009   052   048   030    Pre-fail  Offline      -       1374444414102
  9 Power_On_Hours          0x0012   092   092   000    Old_age   Always       -       7678
 10 Spin_Retry_Count        0x0013   100   100   090    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0013   096   096   000    Pre-fail  Always       -       4978
197 Current_Pending_Sector  0x0030   100   100   000    Old_age   Offline      -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       12

A moje nastavení:

/dev/hda:
 multcount    = 32 (on)
 IO_support   =  3 (32-bit w/sync)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 19846/16/63, sectors = 20005650, start = 0

Staré Seagaty doporučuji, jsou levné a opravdu kvalitní například oproti WD, nebo IBM (ale to jsou jenom moje zkušenosti)...

[qk]

no ja mam zase 8 let stary IBM, dokonce dva a zadnej problem sem nezaznamenal. I kdyz sem nezkousel jestli umi smart a pripadne co to vypisuje, zkusim az se dostanu domu.

[andree]

tak to asi dost dobre tyram svoj disk, hadam ze vo veku 6 rokov uz bude mierne mrtvy.. teraz ma 3/4 roku a mam tam uz

  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       3270
  9 Power_On_Hours          0x0032   092   092   000    Old_age   Always       -       3435

ale prednedavnom som si uz vsimol nejake divne zvuky, ako keby nemazali loziska (keby tam ovsem nejake boli - tipujem, ze uz na vacsine/vsetkych (aspon 2.5'') diskov su fluidne :))

[andree]

aj ked popravde ten start-stop mi pride nejaky prilis drsny, kedze notebook zapinam+vypinam max. 2-3x denne...

[cezz]

Pravdepodobne sa vypina sam po nejakej dobe necinnosti.

[mess]

Tohle píše můj cca 6letý Samsung.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   051    Pre-fail  Always       -       4
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       4035
  5 Reallocated_Sector_Ct   0x0033   253   253   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   253   253   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0024   253   253   000    Old_age   Offline      -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       882820
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1773
194 Temperature_Celsius     0x0022   133   100   000    Old_age   Always       -       35
197 Current_Pending_Sector  0x0033   253   253   010    Pre-fail  Always       -       0
198 Offline_Uncorrectable   0x0031   253   253   010    Pre-fail  Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   100   100   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000b   100   100   051    Pre-fail  Always       -       0
201 Soft_Read_Error_Rate    0x000b   100   100   051    Pre-fail  Always       -       0

To vypadá celkem dobře, ne? zvlášť když na začátku mám

SMART overall-health self-assessment test result: PASSED

[xxxxxxxx]

jakym prikazem si to vykouzlil pls?

[XMurder]

Ahoj, já to řeším takhle:
smartctl -A /dev/hda
Viz. třeba článek na Linuxexpres.cz

[Petr]

Hm můj 60G IBM vypadal stále dobře až se jednou zasek (prakticky byl počítač jen zapnutý a nic momentálně nedělal). No když nereagovala klávesnice ani myš a v síti není tak nezbývalo než ho natvrdo vypnout. Pak už jsme se nikdy neviděli a to ani v biosu.

[krnoha]

Vypínač reagoval, to máš teda kliku.

[e.lisak]

ta polozka

Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       882820

se mi nejak nezda...

pokud je to v hodinach, tak to odpovida dobe nejakych 100let

Pro ilustraci jeden 3 roky stary Seagate:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       758
  9 Power_On_Hours          0x0032   074   074   000    Old_age   Always       -       23465
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       433

(jsou uvedeny jen nektere polozky)

[petr_p]

SMART je dobra vec, bohuzel:

• nektera pocitadla maji maly rozsah, takze za zivot disku se dokazi nekolikrat pretocit
• i kdyz smartctl tvrdi, ze disk ma v databazi a tudiz rozumi syrovym hodnotam, tak ukazuje obcas blbosti (napr. vysse uvedeny vypis, podivejte se na teplotu)
• jeste nikdy me smart demon nevaroval, ze by se disk chystal do kremikoveho nebe, ale presto se tam necitelne sektory objevovali pravidelne

Historka: nedavno jsem menil 5 let stary disk, protoze si obcas vymejslel a posilal nesmyslny data (samozrejme SMART i badblocks mlceli). Nahradil jsem jej 3 roky starym diskem se kterym problemy nebyly. Kdyz jsem kopiroval system a pak jej overoval, nesli precist cele sekvence sektoru. Disk jsem mel totiz prevraceny (vzhledem ke gravitacnimu poli). Otocil jsem ho zpet a najednou vse bylo v poradku.

[mess]

...podivejte se na teplotu

Hm, 35°C se mi nezdá jako nereálná hodota.

[petr_p]

A beru zpet. Znovu jsem si precetl manual a bud to zmeninili, nebo jsem si to blbe zapamatoval: RAW je casto v prirozenych jednotkach, ale byt nemusi. VALUE je normalizavana na 255. Normalizaci provadi sam disk.

(Mel jsem za to, ze to je obracene, v cemz me utvrzoval jeden disk, ktery tu teplotu nenormalizuje. Proto me tady VALUE 130 vydesilo a 121 na mem novem disku jsem povazoval za chybu.)

[František Ryšánek]

Ten popis je velmi dobrý Doporučuju ve smartctl -a koukat i na error log. Pokud obsahuje nějaké chyby, je to nejlepší indikátor, že se něco děje a co se přesně děje.

Když disk při pokusu o čtení zjistí, že narazil na vadný sektor, tak to může dopadnout několika způsoby:

1) čtení trvá o něco déle, ale proběhne, a disk provede transparentní relokaci sektoru (nedojde ke ztrátě dat)

2) disk po pár pokusech vrátí OS chybovou hlášku, že "DriveReady SeekComplete Error". A pak sektor realokuje bez záchrany dat, tj. netransparentně. Takže při novém pokusu o čtení sektor přečte z náhradního umístění, ale jsou v něm halušky. Tato chyba by se měla správně objevit ve SMART logu.

3) disk se odmlčí, OS nahlásí timeout ATA/SCSI příkazu. Po rebootu se disk buď sebere a tváří se jako že nic (správně by mu měla přibýt chyba ve SMART error logu resp. "Grown defects listu"), nebo už to nerozchodí.

Obdobně to může dopadnout při zápisu, i když tady mi není jasné, nakolik disk může při zápisu odhalit vadný sektor, zda dělá validaci zapsaných dat, nebo zda prostě v některých případech nedokáže zaseekovat na stopu (nalézt pod hlavou naváděcí režijní značky)... - domnívám se, že B je správně.

Obvyklé chyby při čtení hlášené samotným diskem jsou dvou druhů: buď disk přečte ze sektoru data, která mají vadný checksum, nebo ani nedokáže zaseekovat na stopu. V Linuxu se tohle dá rozlišit z chybového kódu, případně ze SMART error logu (obsahuje tytéž informace). Interpretace ATA příkazů a chyb se dá dohledat na internetu.

No a pak jsou odchylky od očekávaného chování. Typický příklad: chyba se nedostane do SMART logu / grown defects listu, disk se při čtení tváří hrozně spokojeně, SMART error log je čistý, ale při pokusu o zápis padne disk na hubu (a po rebootu opět to samé). On totiž SMART ukládá svoje data taky jenom do nějakého režijního "SMART" sektoru na plotně (doslova 512 B), který není přímo adresovatelný. No a když má fatální problém se zápisem, tak už nezapíše ani ten SMART sektor. Taky se vyskytují bugy ve firmwaru disků. Přijde mi, že některé disky třeba na error log vysloveně kašlou.

Některé disky mají SMART "vypnutý". To se pozná ve chvíli, kdy se pokusíte o smartctl -a. Dá se pomocí této utility zapnout. Není mi ale jasné, zda ve vypnutém stavu disk vede statistiky (a je pouze vypnuté vnější rozhraní SMARTu), nebo zda při vypnutém SMARTu disk prostě nic nesleduje.

V RAIDu může být jistě problém s nějakým vaklem v hot-swap rámečku, nebo s přehříváním elektroniky disku - pak se chyba "opraví" vytažením a zasunutím disku. Podobně se ale chová disk při netranspaentní realokaci sektoru - ta by měla být vidět ve SMARTu, nejlépe jak ve statistice tak v error logu. Ostatně by měla být vidět taky jako událost v logu RAIDu, pokud RAID takovou věc má.

S RAIDy obecně je ten problém, že není vidět přímo na disk, takže nelze použít smartctl/scsiinfo - ledaže vypnete RAID a disky si připojíte na prostý HBA nebo onboard SATA kanál. Různé RAIDy poskytují různou úroveň podrobností ze SMART statistiky jednotlivých disků. Docela dobře je na tom Areca, z ní lze například vyrazit kompletní statistiky (surový SMART sektor) na dálku pomocí ovládací knihovny přes TCP/IP, inband přes SCSI nebo u interních PCI karet přímo přes PCI. (Něco se dá taky zjistit pollingem přes SNMP.) Bohužel ale nejde získat SMART error log - v hlavičkovém souboru knihovny je poznámka, že "tento SMART příkaz není implementován", patrně ani ve firmwaru. Nejedná se o prosté passthrough ATA SMART příkazů, číselné kódy příkazů jsou jiné.

Periodickou kontrolu povrchu disků umí tuším jakýkoli Adaptec AACRAID (SCSI, SATA, SAS), údajně má něco na ten způsob Areca apod. Externí Accusys umí dokonce nastavit den a hodinu, kdy se má scrubbing spustit (ale má zase jiné mouchy). SMART sledují i ty nejlevnější externí RAIDové řadiče od Arecy a Accusysu. U interních RAIDů do PCI nemám přehled (kromě Arecy). U dražších a větších storage mrazáků taky nemám tušení.

Na vícečetné výpadky disků je dobrý RAID6 - přežije výpadek libovolných dvou disků.