S.M.A.R.T. testy
Třetí a poslední funkcionalitou, kterou S.M.A.R.T. poskytuje, je testování pevného disku (tedy jakási samodiagnostika). Tyto testy probíhají na pozadí, lze je tedy použít i na běžícím systému. Je jasné, že intenzivní práce s diskem průběh příslušného testu pozdrží.
Testy jsou celkem tři, krátký (short), dlouhý (long) a "přepravní" (conveyance). Každý z těchto testů dělá něco malinko jiného, krátký testuje základní funkčnost disku, dlouhý provádí totéž, ale trošku důkladněji (a kromě toho testuje i povrch disku) a conveyance test je schopen určit poškození disku způsobené přepravou (ne všechny pevné disky jej ale umí provést).
Délka testů se liší model od modelu, přičemž očekávanou délku testu se dozvíte už z celkového výpisu (smartctl -a /dev/disk
):
Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 235) minutes.
Testy je možné zadávat a vyhodnocovat opět pomocí nástroje smartctl
a přepínače -t
. Krátký test se spustí příkazem:
smartctl -t short /dev/sda
U dlouhého testu se u parametru -t
použije hodnota long
, a u přepravního testu se použije hodnota conveyance
. Pokud test tímto způsobem zadáte, objeví se vám podobný výpis:
debian ~# smartctl -t short /dev/sda smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Short self-test routine immediately in off-line mode". Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 2 minutes for test to complete. Test will complete after Tue Jan 12 15:47:26 2010 Use smartctl -X to abort test.
Z výpisu se dozvíte očekávanou dobu trvání testu i očekávaný čas jeho dokončení. Nástroj smartctl
vám také radí, že test lze zrušit pomocí parametru -X
.
Výsledek testu se dozvíte opět z výpisu smartctl -a /dev/disk
:
SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 2290 - # 2 Extended offline Completed without error 00% 302 - # 3 Short offline Completed without error 00% 83 - # 4 Extended offline Completed without error 00% 70 - # 5 Extended offline Interrupted (host reset) 40% 65 - # 6 Extended offline Completed: read failure 90% 27 14566144 # 7 Extended offline Completed: read failure 90% 26 14566144
Zde vidíte celkem sedm testů, jsou seřazeny inverzně dle doby, kdy byly provedeny. Všechny typy testů kromě třetího jsou "dlouhé" (long), čtyři naposledy prováděné testy (1-4) nevykazují žádný problém, pátý test byl přerušen restartem počítače zhruba v 60% průběhu, přičemž šestý a sedmý skončil s chybou. U těchto dvou testů vidíte i číslo bloku (14566144), kde k chybě došlo.
Tento výpis náleží disku Hitachi, kterého se týkal onen problém s výpadkem napájení a následné nekonzistenci mezi ECC záznamem a daty v osmi sektorech, která vyvolala chybu čtení. Srovnejme to nyní s výpisem ze S.M.A.R.T. logu:
Error 36 occurred at disk power-on lifetime: 27 hours (1 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 08 00 43 de e0 Error: UNC 8 sectors at LBA = 0x00de4300 = 14566144 ...
Jak je vidět, číslo bloku se shoduje (14566144). Z výpisu testů je jasně patrné, že tato chyba byla odstraněna (pozdější testy proběhly bez chyby) a nulová hodnota S.M.A.R.T. atributu "reallocated sectors count" potvrzuje, že se nejednalo o špatné sektory, které by bylo nutné přemapovat. Tento disk je tedy zcela v pořádku.
S.M.A.R.T. monitorování
Hodnoty S.M.A.R.T. atributů je možné sledovat prostřednictvím démona, který bude zachytávat změny hodnot a ve výchozí konfiguraci zapisovat změny do systémového logu. Tento démon je součástí balíčku smartmontools
, tudíž pokud máte nainstalován ten, stačí démona jen povolit.
V Debianu je za tímto účelem třeba upravit konfigurační soubor /etc/default/smartmontools
a odkomentovat následující řádku:
start_smartd=yes
Démona je možné konfigurovat i poněkud precizněji, a to prostřednictvím konfiguračního souboru /etc/smartd.conf
. V něm je možné nastavit mj. kupříkladu zasílání varování o změnách na zadaný e-mail.
Parkování hlaviček a úsporný režim disků
Jedním z atributů, jehož hodnoty S.M.A.R.T. sleduje, je i počet zaparkování hlaviček disku (load cycle count) za celou dobu jeho života. Toto množství je totiž svým způsobem omezené - výrobci disků udávají vždy pouze určitý počet parkování, které by disk měl zvládnout. Desktopové a serverové disky obvykle zvládnou podstatně méně než disky určené pro notebooky (kde je parkování vítaným prostředkem jednak pro ochranu pevného disku před poškozením daným manipulací s notebookem, a jednak jako součást procesu řízení spotřeby).
Pevné disky mají obvykle vlastní systém řízení spotřeby (power management), který lze u řady disků ovlivňovat parametrem -B
nástroje hdparm
, jehož hodnoty jdou od 1 do 255 s tím, že u jedničky dochází k maximálnímu šetření energie, zatímco u 254 by měl být maximálně zohledněn výkon (na úkor spotřeby). Hodnota 255 by měla řízení spotřeby vypnout (ne všechny disky ji bohužel podporují). Hodnoty od 1 do 127 povolují zastavení disku (spindown), hodnoty od 128 výše nikoliv. Nastavení hodnoty režimu řízení spotřeby by se u konkrétního pevného disku provedlo příkazem:
hdparm -B 128 /dev/disk
Pokud byste chtěli disku zabránit v parkování hlaviček a parametr -B
by nepomohl, můžete ještě disku nařídit, ať neprovádí zastavení disku:
hdparm -S 0 /dev/disk
V případě domácích serverů byste asi řekli, že se jich tato problematika netýká. To jsem si myslel také, dokud jsem nenarazil na jednu sérii úsporných disků jisté značky, u kterých docházelo k příliš častému parkování hlaviček, a aby to nebylo tak jednoduché, příslušné disky nereagovaly na adekvátní příkazy hdparm -B
a hdparm -S
. Jediné, co zbývalo, byla úprava firmwaru (já jsem se do ní nepouštěl a disk raději rovnou vyměnil).
Bohužel, snaha o úsporu energie, související marketing a možná laxní přístup některých výrobců k testování svých pevných disků pod více operačními systémy, může vést k podobným nepříjemným situacím.
Z tohoto důvodu nebývá úplně od věci kontrolovat u pevných disků i počet parkování hlaviček (load cycle count):
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 4789
Pevné disky obvykle snesou hodnoty v řádu desítek až set tisíců, u notebookových disků tato hodnota může být i 500000. Záleží na konkrétním modelu. Příliš rychle rostoucí hodnotu load cycle count je vhodné řešit způsobem naznačeným výše. Debian nastavuje hodnoty hdparm
při bootu, a tyto hodnoty lze upravovat i pro jednotlivé disky v konfiguračním souboru /etc/hdparm.conf
.
Vývoj pravděpodobnosti selhání disku v čase
Statistická pravděpodobnost selhání pevného disku není po dobu jeho existence stejná. Vzhledem k přepravě a výrobnímu procesu je zvýšená pravděpodobnost selhání disku během prvních měsíců jeho užívání (proto se také vyplácí provádět zátěžové testy). Poté pravděpodobnost selhání klesne, a s rostoucím časem opět roste (disk stárne).
Z toho vyplývá jediné - příliš mladému a příliš starému disku byste neměli bezvýhradně věřit. I proto se vyplatí diskové pole obměňovat postupně v delším rozmezí, spíše než naráz. Kandidáty na vyloučení vybírejte s ohledem na S.M.A.R.T. údaje (disky s realokovanými sektory nebo s nenulovou hodnotou u některých kritických atributů by měly být vyměněny v první řadě).
Jak pomoci S.M.A.R.T.u, když si nejste jisti
Pokud si u pevného disku nejste jisti jeho zdravím, a nemáte na něm důležitá data, můžete S.M.A.R.T.u trošku pomoci použitím programu badblocks
a jeho read/write testu. Ten můžete spustit příkazem:
badblocks -s -w /dev/disk
Pozor - tímto příkazem přepíšete všechna data na daném pevném disku! Pokud si nemůžete dovolit data přesunout, můžete použít dlouhý S.M.A.R.T. test, který povrch disku prověří.
Tím bych problematiku S.M.A.R.T. uzavřel. Příště se budu věnovat praktické stránce LVM, a poté dm-crypt/LUKS.