Portál AbcLinuxu, 28. října 2025 15:50
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.
Tiskni
Sdílej:
11.12.2006 15:12
David Ježek | skóre: 83
| blog: Mostly_IMDB
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.
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 - 12A 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 = 0Staré Seagaty doporučuji, jsou levné a opravdu kvalitní například oproti WD, nebo IBM (ale to jsou jenom moje zkušenosti)...
11.12.2006 17:19
andree | skóre: 39
| blog: andreeeeelog
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 3270 9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 3435ale 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 :))
11.12.2006 17:22
andree | skóre: 39
| blog: andreeeeelog
11.12.2006 18:35
mess | skóre: 43
| blog: bordel
| Háj ve Slezsku - Smolkov
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 - 0To vypadá celkem dobře, ne? zvlášť když na začátku mám
SMART overall-health self-assessment test result: PASSED
Power_On_Hours 0x0032 099 099 000 Old_age Always - 882820se 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)
12.12.2006 18:25
mess | skóre: 43
| blog: bordel
| Háj ve Slezsku - Smolkov
...podivejte se na teplotuHm, 35°C se mi nezdá jako nereálná hodota.
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ů.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
11.12.2006 17:02
12.12.2006 10:37
3.4.2007 08:02