Smartmontools jsou i pro Windows, zda to chodi na Intel raidu nevim
http://sourceforge.net/projects/smartmontools/files/smartmontools/6.1/
Pro starší verze (myslím do ATIH 2012, pak je to již myslím součástí balíku) existoval nástroj Acronis Drive Monitor, který spolupracoval se zálohovacím SW.
V supportu je tento nástroj stále odkazován, ale odkaz pro stažení zmizel. Nevíte někdo proč, nebo co je s tímto nástrojem?
http://www.acronis.eu/homecomputing/products/drive-monitor/
Já ho blbec smazal, svého času jako nepotřebný, dnes bych ho potřeboval.
Dříve býval i na každém DVD v časopisech, ale dnes ho nemohu získat ani na archive.org. Support Acronisu nereagoval, asi nebudu perspektivní zákazník (nekupuji každý rok o něco horší SW).
http://www.slunecnice.cz/sw/acronis-drive-monitor/
Zrovna jsme ho stahnul...
Díky Tome. Hledat na Slunečnici mne fakt nenapadlo.
Mám ale několik ALE, třeba mi pomůžeš je rozlousknout.
1. Balik (instalátoru) není podepsán. Nicméně vlastní DriveMonitor.msi již je, datum 4.6.2010, mělo by jít o verzi 1.0.187 (informace uložená mimo vlastní MSI balíček).
2. SHA256 kontrolní součet mnou staženého EXE je a8c0e7b138953f4d0aca0fc1d95d1be4a994bcaea5890e8ef7466a1a8fe64de7 Žádný VirusTotal ani jiný známý mi nástroj na webu nepozná tento kontrolní součet.
3. Support Acronisu uvádí build 566 (velikost 18.1 MB) a datum 1.3.2011. Jejich Release Note pak obsahuje pouze informaci o buildu 507 ze dne 23.9.2010
4. Na české lokaci Acronis.cz je Drive Monitor (http://www.acronis.cz/prihlaseni/adm/) ke stažení až po přihlášení. Přestože jde o produkt zdarma, ale chápu že byl primárně určen pro uživatele Acronis produktů. Verze uvedena není, pouze že jde o anglickou jazykovou mutaci.
S tou českou lokací Acronis.cz je mnohem více problémů. Já mám klasický účet u Acronis COM/EU. Češtinu vůbec neuvádí mezi podporovanými jazyky ani o jejich webu neexistuje žádná zmíňka, přestože informace v krabici o CZ jsou přiloženy, nicméně výzva pro registraci je pro COM/EU web.
Je mi proti srsti přihlásit se na acronis.cz pomocí udajů k účtu na acronis.com/acronis.eu protože jednak nevím jestli to vůbec jde (zda přihlašovací údaje jsou sdíleny), jednak nevím zda by neoprávněně nezískali moje přihlašovací údaje. Dotaz zaslaný Supportu byl opět ignorován. Oni řeší akorát chyby a jen v předplacené/zaplacené lhůtě - a ještě stále více takovým stylem, že opravdovou chybu (a že jich mají) nejde nahlásit.
Má někdo zkušenost ohledně těch účtů?
Zdá se, že na Softpedii mají tu poslední, správnou a oficiální verzi - Acronis Drive Monitor 1.0 Build 566
http://www.softpedia.com/get/System/Hard-Disk-Utils/Acronis-Drive-Monitor.shtml
P.S.
Znovu jsem poslal žádost supportu, ale nic si od toho neslibuji. Tentokrát jsem navíc ani neobtěžoval přihlásit.
P.P.S.
Dotazy kolem Acronic.cz řeším dále. Máte nějaké osobní zkušenosti. Základal u nich někdo účet? Jsou účty sdílené? Nějaké úniky klíčů? Stojí jejich podpora vůbec za něco, nebo je to stejná tragédie jako u acronis.com/eu?
Este by som dodal mojich par skusenosti:
1. Ked sa disk "zacina lucit", tak zrazu zacne prudko stupat hodnota "Reallocated Sector Count". A niekedy aj "Current Pending Sector". Pri starsich diskoch (80-320G) sa mi stalo, ze sa par sektorov relokovalo, potom to prestalo a disk funguje dalej. Pri novsich diskoch (1T+) mam skor tu skusenost, ze ked to zacne, uz sa to len zhorsuje a treba urychlene kupit novy disk.
2. Isty cas mali WD disky od vyroby zle nakalibrovany senzor teploty (alebo bol zle umiestneny) a hlasili prilis vysoke teploty (disk bol na dotyk uplne studeny, ale SMART hlasil teplotu 65 stupnov Celzia). Jeden taky som kupil, hned som ho reklamoval. Dostal som druhy, kde bol uplne ten isty problem (az potom som si precital na nete, ze je taka cela seria). Ten disk dodnes slape (cely komp som ale medzicasom posunul, takze neviem do detailov v akom stave je ten disk).
3. Po kupe noveho disku, este predtym nez na disk dam nejake data, vzdy najprv pozriem SMART, potom zbehnem badblocks -svw a potom opat skontrolujem SMART. Uz som tak reklamoval dva uplne nove disky. Pred badblocks ziadne realokovane sektory, po badblocks vela, plny log SMART chyb a odvtedy kazdy long test skoncil chybou. Inak sa disk tvaril ako funkcny, bez SMARTu by som asi nemal sancu zistit, ze mu nieco je.
Sice badblocks pri vacsom ako 1T disku trva viac nez 24 hodin, ale stoji mi to za to. Az tak vela som tych diskov nekupoval a to, ze 2 boli zle uz od vyroby, sa mi zda prilis vysoke cislo...
1. To sedi s mym pozorovanim. Jde videt ze narozdil od "analytickych vocasu" jsi prakticky a vnimavy clovek.
V teto souvislosti jsem i zjistil ze nezalezi na tom jestli to jsou starsi lowendove disky nebo hiend. Troufam si odhadnout ze to souvisi se zmenou technologie hlav a zaznamu.
3. Badblocks je k nicemu. To bylo tak dobry na velmi stary disky s hloupym fw co neumel realokovat (v radu MB) nebo diskety.
Na soucasnych lowend discich zalezi hodne na tom jestli zpetne vraci zjistene chyby elektronika disku (resp. firmware) do ATA/SCSI commandu nebo ne. Mam zkusenost ze disky dnes delaji mrtveho brouka (nereportuji v ATA/SCSI chyby) i kdyz na pozadi realokuji jako blazen. V pripade nemozne realokace uz pak jen smutne sleduji timeouty.
Na poruchy se prijde az z smart counteru nebo u novejsich disku z logu. Dalsi veci je ze muze ukazovat false positive chyby pokud je problem v kabelazi nebo s radicem i kdyz je disk samotny v poradku. Na tyto poruchy pomaha prohlednout si log neuspesnych prikazu z disku a counter chyb na rozhrani.
Takze badblocks ve smyslu zjisteni spatnych bloku zbytecny. Nicmene jeho vedlejsim efektem je ze procvici cele plotny na zaznam/cteni. Coz odhali chyby na ktere by se pak prislo az pozdeji pri provozu.
Cele plotny by mel analyzovat i long test, ale vzhledem k tomu ze krom vyrobce nevime co dela pri testech firmware disku na pozadi a kazdy fw je jeste jiny, tak verim jen provedenemu celemu zapisu/cteni/random seeku na vyssich urovnich (ATA/SCSI prikazy).
Misto badblocks je lepsi parkrat na disk nadojit ddckem /dev/zero a /dev/urandom po vetsich blocich. Pak udelat par cyklu s ddckem na random seek/write. Random seek/write delaji i samotne smart testy ale jak rikam. Clovek muze pouze verit ze neco takoveho delaji protoze je to blackbox.
Vyhoda je ze tato metoda funguje na unixovych systemech kde zadny badblocks nemam.
1. predrečník jasne napísal, že používa kombináciu badblocks+porovnanie SMART counterov pred/po
2. disk môže realokovať až pri zápise. Pri čítaní, ak ani po interných retry cykloch nesedí CRC sektora, môže akurát tak vrátiť chybu (a označiť si sektor ako "pending"). Badblocks sa dá celkom úspešne použiť na dump zoznamu LBA sektorov, kde disk vrátil nejakú chybu. Následne sa dá napr. skúsiť prepísať ich pôvodným obsahom (resp. teda tým, čo z neho zostalo), na spôsob takéhoto RW refreshu:
dd if=/dev/sdX of=/dev/sdX bs=512 iflag=direct oflag=direct conv=noerror seek=LBA skip=LBA count=C
Zápis na ten "pending" sektor sa vtedy buď podarí (a vyradí ho z pending listu), alebo nepodarí a realokuje ho.
Prípadne sa ten RW refresh dá preventívne spustiť na celý disk (ak je záloha, tak kľudne aj s rádovo väčším bs - tak, aby napr. trebárs sekundu bez seekovania lineárne čítal a následne seekol späť a obsah zapísal). Samozrejme vtedy bez seek/skip/count parametrov.
To "vracení zjištěných chyb"...
V EventLogu System (Windows) mám tři zdroje událostí - Disk, DiskDiagnostic, Windows Disk Diagnostic.
Během posledních let byl zdrojem událostí pouze Disk.
Kromě varování při chybách stránkování a hlášení chyb řadičů, vše na výměnných discích, ukazuje pro stabilní disk jen tyto události (nekritická chyba, dva výskyty hned po sobě):
Zařízení \Device\Harddisk1\DR1 má chybný blok.
Zařízení \Device\Harddisk1\DR1 má chybný blok.
To je informace z HDD, nebo si ji zjistil systém při čtení? Pokud si to zjistil systém sám, tak ty dva výskyty po sobě, to je opakování pokusu, nebo detekce dvou vadných bloků (celkově má HDD realokované čtyři sektory, ve FAT nejsou žádné sektory označené jako uzamčené)?
Pokud vadné sektory zjistil systém, komunikuje pak nějak s HDD a oznámí mu chyby?
Děkuji za případnou osvětu.
Tahle hláška se vyskytne až při přístupu na vadný blok. Disk samotný nic iniciativně neposílá, to by se vám taková hláška musela objevit kdykoliv při připojení "načlého" disku. Nemám tu hlášku před sebou, ale pokud tam není adresa bloku, tak z ní nepoznáte, jestli to byly 2 vadné bloky, nebo se snažil 2 x zapsat do stejné oblasti. Ve smartu HDD by se to mělo objevit jako pending sektor, dokud se mu to nepovede realokovat. Není potřeba, aby o tom systém pak komunikoval s HDD - HDD to ví jako první, on tu chybu při čtení zjistí a posílá ji systému. Zároveň si ji zapíše.
Jaké by měly být běžné pracovní teploty notebookových HDD (2,5 palcových)? Běžně se uvažuje s teplotou 42°C jako varování, 52°C jako kritická.
Můj HDD dosáhne teploty 42°C asi po hodině práce notebooku. Pak kolem ní kolísá, ale pod těch 42°C klesá teplota jen při "spoření" (uživatel není neustále aktivní), nebo při mnohahodinovém (spíše více denním) zapnutí kdy vše důležité je již v paměti a disk se používá spíše nárazově.
Při velkém zatížení disku se ale stane, že teplota může být třeba i několik hodin 43-45°C. Přesto je notebook v místě HDD chladnější než mnoho jiných notebooků, které jsem měl v ruce.
U mne jde o disk Toshiba (SATA 3Gb/s), který je vybaven zvukovou signalizací. Dodnes nevím přesně čeho (web Toshiby nikdy nebyl sdílný, dnes tam nejsou ani tyto informace).
Mělo by jít o překročení kritické teploty (která ale nevím kolik je stupňů). Signalizace se ozvala za životnost disku 3x (pokud vím) a i když bylo opravdu horko a disk jel naplno, nezdá se mi že by byla překročena teplota 52°C. Realokovány jsou celkem 4 sektory.
Náhradní disk, který mám připravený a už se chystám na generační výměnu uváděl (informace opět na webu Toshiby již nejsou dostupné) pracovní teplotu 5-55°C. To je předpokládám teplota na senzoru uvnitř disku.
Chápu správně, že to znamená že při teplotě 55°C na plotnách ještě nejsou data v ohrožení? Zvukovou signalizaci by měl mít, ale opět nevím jak nastavenou a čeho všeho se má týkat. V úvahu připadá ještě G-senzor a prakování hlaviček - což by měly dnešní disky dělat do 2 ms, ale to je vše co o tom vím. Jaký je rozdíl mezi 300 G a 400 G netuším.
Jak topí vaše disky?
Antivirový scan (který disk celkem zatěžuje) dokáže zmíněnou stabilní teplotu 42°C s přehledem zvednout až na 47°C.
Věřím, že u kompletních skenů, které trvají mnoho hodin a procesor i disk jedou prakticky naplno bych počítal i s o 1-2 stupně vyšší teplotou. Ale momentálně takový test nemohu provést.
Tak teploty 52°C u starého HDD už bylo dosaženo a zvuková signalizace se neozývá. Snad se tedy ten kravál aktivuje až při zmíněných 55°C.
Kromě teploty zaznamenává S.M.A.R.T. i hodnotu 220/DC - Disk Shift. Je stále stejná a ani při práci za uvedených teplotních podmínek RAW hodnota nevzrostla.
Presne ako sa tu pise v clanku je dolezite sledovat zmeny a nie konkretne hodnoty.
Na nasich serveroch sme si generovali graf hodnot zo smart a napriklad podla premenlivej teploty hdd presne na hodinu denne sme presunuli server do inej police aby na neho nesvietilo slnko cez stropnu spehirku. A vsimli sme si aj zadrety ventilator v hdd klietke - v strojovni si to technici koli hluku nemali ako vsimnut.
Google vsak par rokov dozadu vydal studiu zalozenu na niekolkych rokoch zaznamov na radovo milionoch diskov a vysledok je, ze smrt disku nie je mozne predpovedat. Statisticky disk zomrie do 3 tyzdnov od spustenia, alebo az po 3 rokoch. Preto zaviedli mesacne testovanie diskov pred ich nasadenim do serverov.
Smart urcite dokaze pomoct - ked sa zacnu realokovat sektory koli vadnym blokom na disku, tak potencialne clovek pride o jeden dva subory, ale aspon si to vsimne skor, nez mu disk vypovie sluzbu uplne.
Kdyz funguje realokace spravne, tak ji na blokove bazi vubec nepoznate. Disk sam ma nad bloky kontrolni soucty a informace zaznamenane i nekolikrat. Dnesni disk je pomerne inteligentni proti tomu co jsme se ucili kdysi.
Neproslo mi rukama tolik ruznych disku jako googlo. Ale z osobnich sledovani spis jsou blbe cele serie. Teploty otackove stejnych disku se pomerne dost lisi +-15 stupnu. Prisuzuji to ruzne metodice umisteni cidla a ruzne konstrukci. Na zivotnost to nema vliv. Rozumne naprogramovany firmware disku samotny disk zastavi pokud doslo k prekroceni maximalni teploty.
Spis diskum skodi spatna poloha, vibrace a hlavne spatne napajeni. Mozna nejaky clovek co se podili na vyvoji disku nakopne proc prvni co zarve pri poruse na napajeni je disk. Predpokladam ze se odkouri napetovy menic, dspcko nebo zesilovace u hlavy.
Vibracemi myslim treba stroje v tovarne nebo reprosoustavy. Nejake nizkofrekvencni houpani v aute prilis nehraje roli.
Pruser u prenosnych disku byva taky pad na zem za behu kdy dochazi k zarazeni lozisek.Takovy disk se uz neroztoci.
Článek je pro začátečníky velmi dobrý, ale pro všech ~10 pokročilejších čtenářů by bylo pěkné (třeba v dalším díle) uvést to, jak se tyto hodnoty mají "vyložit", já to třeba vím, ale myslím, že tu jsou ještě tak další 2-3 lidé, kteří to ví také, ostatní na ty čísla koukají jako na hozené runy a odhadují z toho výsledek. Kupodivu SMART je do jisté míry blbuvzdorný, proto prudký nárůst podezřelých atributů často znamená problém.
Viz vejs, jak pise Nasir - co znamenaji ty cisla je stejne nanic (protoze si to stejne kazdej vyrobce vyklada trochu jinak ... dokonce klido i model od modelu). Dulezity je sledovat zmeny => kdyz dojde nejaky razntni zmene = je treba zjistit, co se deje, protoze to muze(a nemusi) znamenat problem.
Ano, je to tak, hodnoty SMART jsou obvykle stejné pro řady disků, tedy není to tak tragické, ale už jsem si všiml, že jistý výrobce změnil výstup spolu se změnou firmware disku.
Ale, pokud chci sledovat důležitý disk, měl bych věnovat svůj čas tomu, abych věděl, co se tam děje.
Například smartctl "vykládá" jednotlivé atributy taky po svém.
Pokud výstup jednoho atributu obsahuje číslo 8-bitů a číslo 24-bitů (typicky pro 16-ti bitová a 32-bitová data) - tak to kóduje výrobce a smartctl to vezme jako jedno číslo dlouhé 32 bitů (což by to být dejme tomu mělo), je to samozřejmě blbost. Je potřeba se podívat na hodnotu RAW a "ručně" si to rozdělit. To se dá dočíst nejlépe v příslušném datasheetu.
Některé chyby mohou poukazovat například na chybný kabel, lidé mají pocit, že když jsou kabely SATA, že problémy už skončily, není tomu tak. Jiné hodnoty poukazují na vadný napájecí konektor, tedy za určitých podmínek.
Pokud do systému přidávám další disk, měl bych si zaznamenat počet startů disků. Pokud na jednom disku narůstají starty například o 1/3 rychleji, je buď vadný kabel, nebo disk má problém. (Při podobném nastavení AAM.)
Ale jsou tu spousty a spousty chyb, tedy není takový problém data přečíst, ale umět je interpretovat, na což by se hodil článek, byť pochybuji, že by se tu našlo dost lidí, kteří by to ocenili.
Kódování dvou výstupů do jedné hodnoty atributu není nijak zvláštní.
Není to tak dlouho, ještě když jsem tu chodil na fórum, se tu někdo ptal, že mu na smartu prudce narůstají hodnoty jednoho atributu. Několik "chytrolínů" mu poradilo, že disk je v háji, ať ho zahodí.
Pokud mám 32 bitové číslo a prvních 8 bitů je pro jeden typ chyby a zbylých 24 pro druhý typ chyby, tak po přečtení "jednoho" 32 bitového čísla to vypadá, že se tento atribut mění naprosto dramaticky. Ono zvýšení o 1 v horních 8 bitech z 32-bitového čísla vždy vypadá dramaticky.
No to je jedno....
Udělal jsem si čas a znovu si přečetl studii Google:
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/cs//archive/disk_failures.pdf
Řadě lidí zde doporučuji, aby si to znovu přečetli, až se naučí dobře anglicky.
• Contrary to previously reported results, we found
very little correlation between failure rates and either elevated temperature or activity levels.
To je velmi zajímavé, obecně se uvádí, že se vzrůstající teplotou klesá životnost a vzrůstá poruchovost.
• Some SMART parameters (scan errors, reallocation counts, offline reallocation counts, and probational counts) have a large impact on failure probability.
Ano, to je samozřejmé, výše uvedené poruchy signalizují poškození povrchu disku.
• Given the lack of occurrence of predictive SMART
signals on a large fraction of failed drives, it is unlikely that an accurate predictive failure model can
be built based on these signals alone.
Ano, samozřemě, jen na základě těchto údajů nelze smrt disku předvídat, především se nedá předvídat "náhlé úmrtí", to SMART neumí a nikdy na to nebyl určený. SMART má předpovídat selhání motoru(roztáčení), což u Google asi netestuje a opotřebení povrchu, což Google testuje a odpovídá mu to.
Pak tu jsou výsledky, první měsíc je obvyklé vyšší selhání, překvapivě to není vůbec dramatické, disky začínají odcházet po druhém roce provozu.
V domácím prostředí to bude 1) prvních 6 měsíců, 3 roky klid, pak cca 10% šance, že disk tento rok chcípne.
Tabulka teplotní korelace je také velmi pěkná.
Obecně by to stálo za to celé to přeložit, aby si to mohli přečíst i ty méně chytří z nás.
Chyby kabelu a radicu obvykle dobre odhali u SATA logy pokud se nebavime o SCSI.
Pokud mam "dulezity disk", tak obvykle to mam s nejakym levelem redundance a tam nic jako dulezity disk neni neb tento je pouze logicky. Pokud mam "dulezity disk" tak i jako maly dodavatel vybiram disk ktery ma proverene hodnoty a mohu tyto globalne monitorovat zkrz x zakazniku. Je jasny ze mam-li na starosti 5 masin tak atributy znam z pameti a vim jak se systemy chovaji. Byvaly doby kdy jsem pozval vadny disk podle sluchu. To ale nelze aplikovat ve vetsim meritku.
I u malych reseni je moznost vyrazne zvetsit spolehlivost pokud mam nakou vuli ovlivnit vyber disku. V pripade sw raidu je pomerne jednoduche zvolit ruzne disky od ruznych vyrobcu. Tedy neco kde proprietarni hw reseni selhavaji na nutnosti mit stejne disky (nekdy i teze serie).
U velkych systemu kde tech "dulezitych disku" je hodne se vubec nestarate o nejake vadne serie nebo disky. Protoze by se z toho clovek zblaznil a musel by na to byt extra tym.
Proste to menite ze skladovych zasob kdyz je "cervena" nebo to za vas dela dodavatel reseni.
Takze jediny co cloveka zajima je co se deje pred polem. Je fakt ze kdyz se sejde serie, tak clovek si pripada jak na cviceni s Powerballem. Nasledny pojeb jde ale systemem volneho padu exkrementu od zakazniku pres dodavatele az na vyrobce disku
Rozhodně data ze SMART nejsou použitelná jako jediný zdroj informací. Já jsem je ale už několikrát použil ke včasné detekci špatného disku v RAIDu - prostě jsem ho vyreklamoval dřív než bych ten RAID nechal dojít až do degradovaného módu. Dodavatelé mi bez potíží u disků které hlási přes SMART chyby akceptují reklamace. Nesnažím se ale o nějaký sofistikovaný dohled, prostě mám jen spuštěný smartd a když mi od něj přijde mail tak disk rovnou reklamuji.
Podle mne jsou nejdulezitejsi tyto dve polozky:
Reallocated_Sector_Ct, ktery ukazuje pocet vadnych sektoru realokovanych z rezervy a Current_Pending_Sector, ktery ukazuje pocet sektoru prectenych s chybou, ktere se pri zapisu nul do sektoru bud presunou do realokovanych, nebo zmizi a tvari se ze jsou OK. V obou pripadech to obvykle znamena, ze povrch disku, nebo hlavicky jdou do haje. Dalsi Spin_Up_Time muze ukazovat na pridrene lozisko motoru. Pak se muze stat, ze pri vypnuti a zapnuti napajeni se disk uz neroztoci. U dlouhodobe bezicich disku se to ovsem ze smartu nepozna.
V zásadě ano, ale dataily jsou důležité.
Reallocated Sector Count = 4
Reallocated Event Count = 4
Current Pending Sector = 0
Matně si pamatuji kdy jsem odstraňoval chybu disku.
Jinak. Na Windows, při prostém čtení S.M.A.R.T. hodnot (RAW Value), testy a ostatní hodnoty jsou nezajímavé, se zobrazuje v tabulce ještě sloupce TYPE (myslím že je výstižný a řídil bych se podle něj) a UPDATED.
ATTRIBUTE_NAME: TYPE (UPDATED)
Raw_Read_Error_Rate: Pre-fail (Always)
Throughput_Performance: Pre-fail (Offline)
Spin_Up_Time: Pre-fail (Always)
Start_Stop_Count: Old_age (Always)
Reallocated_Sector_Ct: Pre-fail (Always)
Seek_Error_Rate: Pre-fail (Always)
Seek_Time_Performance: Pre-fail (Offline)
Power_On_Hours: Old_age (Always)
Spin_Retry_Count: Pre-fail (Always)
Power_Cycle_Count: Old_age (Always)
Power-Off_Retract_Count: Old_age (Always)
Load_Cycle_Count: Old_age (Always)
Temperature_Celsius: Old_age (Always)
Reallocated_Event_Count: Old_age (Always)
Current_Pending_Sector: Old_age (Always)
Offline_Uncorrectable: Old_age (Offline)
UDMA_CRC_Error_Count: Old_age (Always)
Disk_Shift: Old_age (Always)
Loaded_Hours: Old_age (Always)
Load_Retry_Count: Old_age (Always)
Load_Friction: Old_age (Always)
Load-in_Time: Old_age (Always)
Head_Flying_Hours: Pre-fail (Offline)
Vyrostl jsem bez SMART, kdy se kondice disku kontrolovala a diagnostikovala poslechem. Když už ten SMART tu dneska je, tak pro kondici disku má význam akorát položka Reallocated sector count. Od doby, kdy pozvolna odešly dva Seagate bez jakýchkoliv změn hodnot jsem se na analýzu a hlídání SMART zcela vyignoroval. SMART není všespásný a reklamace u obchodníka neuspěla. Nicméně jsem jejich chování v systému postřehl sluchem a jinými nástroji sledoval jejich úhyn. To jsem spolu s disky poslal výrobci na blind co on na to, když SMART je v okeju a obratem jsem od nich dostal náhradní o dvojnásobné kapacitě, i když původní kapacita ještě byla na trhu. Tím i Seagate potvrdil, že SMART nepokryje všechno.
Pro sebe beru jen Seagate, protože když odchází, tak civilizovaně, a žádný nezdechl na fleku. Třeba tento od nova závratným tempem zvyšuje hodnotu Reallocatin error count a smartctl na tuto hodnotu barevně upozorňuje. Tedy důvod k panice. Jenže u tohoto disku to je navázáno na hodnotu Reallocation sector count a ten pokud je na nule, tak se nic neděje. Když byl nový, tak je vypůjčily wokna a udělala se v HD Tune Speedmap. Barevně byl disk na vyřazení, což odpovídalo i raketovému růstu REC. Tedy tato hodnota nadále úspěšně roste a proto jsem disk přešel po 1 500 hodinách znovu vypůjčeným HD Tune. Překvapivě Speed map je krásně stejnoměrně zeleňoučký pozvolna ke konci přecházející do slabě žluté jak má být. Seagatí disk je podle barev v lepším stavu než, když byl nový :-))) Další důvod pro ignoraci udělátek na kontrolu stavu disku. Akorát ztráta času.
Ve firemním prostředí také už nikdo SMART nesleduje. Holt se rožne světýlko, že disk zdechl, šupne se tam jiný, tento se hodí do bedny a jede se dál.
To bude spise silent data corruption, tedy ze po vipnuti smaze nektere chyby ze SMART.
Co se smart tyce, spolehaji na nej vsechny RAID pole, sice ci inegritu kontroluji i samy, ale kdyz hlasi neco SAMRT, tak jej bud vyradi, nebo poslou hlasku.
Nekektere pole umoznuji jeste prepsat cely disk a kdy je vse OK, zaradi jej do spare, kdyz pandou, vyradi je uplne a oznaci za vadne.
Neketer je oznaci za vadne hned a vyndanim a zandanim je lze zkusit pouzit, bezne tzv. RAID disky se vestinou jeste cytnou a jedou i rok, kdyz ale vypadnou pak, vetsinou uz nahodit nejdou, max se to pry povede 3x, pak uz jej raid vyradi behem rebuildu .... lepsi pole maji OEM disky, vetsinou od Seagate a tam maji svuj FW pro svoje pole, hlidaji si tam taky chyby a sami si za behu upgraduji FW
Spoléhat na SMART je jako veřit předpovědi počasí na příští léto, statisticky z dlouhobého hlediska to v průměru nějak vyjde i když vám celá dovolená proprší. Klasická situace: Disk se roztočí zacvaká (pokouší se o self test) a zastaví, hotovo mrtvola. Nějaká ta "léčba šokem" a disk se chytil, kompletně čitelný, zvednuté počítadlo star/stop, provozní hodiny, ale žádné kritické atributy které by ukazovaly že disk přežil klinickou smrt. Short/Long test, diagnostické utilitky, všechno ukazuje že disk je v pořádku. Pochopitelně nebyl a do týdne odešel definitivně. A takových jsem potkal víc, kdy se testy se tváří že je všechno v normě předtím i potom (pokud nějaké potom ještě vůbec je). Úplně SMART nezatracuju, určité anomálie najde a v poli s mnoha disky má šanci něco odhalit ale u klasického desktopu je ucho spolehlivější.
Něco podobného se mi stalo také, ale mělo to zajímavou dohru.
Doma mi odešel disk (toho času 80GB IBM na IDE). Začalo to občasným zacvakáním, zastavením a novým roztočením. Na sběrnici se sice hlásil, ale číst se z něj příliš nedalo (zkoušel jsem na více počítačích). SMART ovšem hlásil, že disk je naprosto v pořádku. Většinu dat jsem měl zálohovánu, tak jsem jej strčil do skříně, že se z něj třeba někdy ještě podaří něco dostat.
Po pár letech jsem na něj narazil a řekl si, že si ho vezmu do práce, rozeberu a přihodím k počítačovému šrotu. Hodil jsem ho v autě do kastlíku u spolujezdce a zapomněl na něj.
Asi po dvou měsících jsem jej tam zase našel, tak jsem ho konečně odnesl do kanceláře a ještě naposled připojil k PC. Disk normálně fungoval a funguje dodnes...
Pak mi někdo říkal, že to mohl být jen problém s kontakty mezi deskou elektroniky a zbytkem elektroniky uvnitř disku a že to napravily ty vibrace v autě.
Kdybych nemel SMART, nemel bych sanci zjistit, ze jeden ze dvou disku v SW RAID1 v Linuxu odchazi. V logu mel errory, spoustu realokaci, atp., druhy disk byl erroru a realokaci prosty. Vymena vadneho (za chodu), rebuild a muzu zase klidne spat.
SMART ma smysl jako zakladni diag. nastroj disku. To mi nikdo nevymluvi.