Podczas rutynowego skanu powierzchni dysków HDD w moim laptopie, S.M.A.R.T wykrył w jednym z nich podejrzany blok, który zdawał się wyzionąć już ducha, przez co proces weryfikacji integralności powierzchni dysku twardego nie był w stanie zakończyć się z powodzeniem. Komunikat zwracany przy czytaniu padniętego sektora też był nieco dziwny: bad/missing sense data, sb[] . Jakiś czas temu już opisywałem jak realokować uszkodzony sektor dysku HDD i w zasadzie wszystkie informacje zawarte w tamtym artykule można by wykorzystać do próby poprawienia zaistniałego problemu, gdyby tylko nie fakt, że w tym przypadku badblock znalazł się w obszarze voluminu logicznego LVM na partycji zaszyfrowanej przy pomocy mechanizmu LUKS. Taki schemat układu partycji sprawia, że do realokowania błędnego bloku trzeba podejść nieco inaczej uwzględniając w tym procesie kilka offset'ów, bez których w zasadzie nic nie da się zrobić. Postanowiłem zatem napisać na konkretnym przykładzie jak realokować badsector dysku, gdy do czynienia mamy z zaszyfrowanym linux'em zainstalowanym na voluminach LVM.

Dyski zużywają się z różnych powodów. Jednak najczęstszą przyczyną są nowe wynalazki, które producent w nich implementuje, bo te niezbyt dobrze działają w określonych warunkach, czy też pod kontrolą pewnych systemów operacyjnych. Tak właśnie jest w przypadku dysków HDD firmy Western Digital (WD). Maja one wprowadzony ficzer parkowania głowicy w przypadku, gdy dysk jest nieużywany (tzw. IntelliPark/IntelliPower). Ma to na celu zmniejszyć pobór prądu i, co za tym idzie, temperaturę urządzenia oraz też uodpornić nieco taki nośnik na różnego rodzaju wstrząsy/przeciążenia. Parkowanie głowicy w dyskach HDD nie działa poprawnie pod linux'em (dystrybucja Debian), tj. parametr SMART Load_Cycle_Count po krótkim czasie użytkowania takiego dysku może osiągać wartości idące w setki tysięcy. Nasuwa się więc pytanie, czy jesteśmy jakoś w stanie wyłączyć to parkowanie głowicy, by wydłużyć żywotność dysku twardego?

Parę dni temu opisywałem jak udało mi się realokować uszkodzony sektor z dysku, który już przepracował dość długi okres czasu. Nie było to znowu jakoś specjalnie trudne, z tym, że cały problem dotyczył jakiegoś losowego sektora gdzieś w środku partycji. Jako, że domyślnym systemem plików na linuxie są te z rodziny ext (ext2, ext3, ext4) , oraz, że trzecia wersja tego systemu plików została wyposażona w dziennik (journal), to trzeba by się zastanowić, co w przypadku gdy taki uszkodzony sektor trafi się właśnie w dzienniku tego systemu plików?

Uszkodzone sektory w przypadku dysków HDD, to jak sama nazwa wskazuje, sektory, które z jakichś przyczyn nie działają tak jak powinny. Doprowadza to z reguły do niestabilności systemu operacyjnego objawiającej się jego zawieszaniem w momencie próby odczytu danych z takiego padniętego sektora. Przyczyny mogą być różne. Zwykle jest to jednak fizyczne uszkodzenie powierzchni nośnika, np w wyniku wstrząsu, czy też zwyczajne zmęczenie materiału. Jest wielce prawdopodobne, że nie jesteśmy w stanie nic poradzić w tego typu sytuacji, a ci bardziej zaawansowani użytkownicy zalecają jak najszybszą wymianę dysku, bo pierwszy bad sektor oznacza, że niedługo będzie ich więcej. Czasem jednak błędy odczytu mogą być programowe, tj. fizycznie każdy sektor jest w porządku ale z jakiegoś powodu system nie potrafi odczytać z nich danych. Przy odrobinie szczęścia jesteśmy w stanie odblokować taki sektor.

Udało mi się znaleźć trochę informacji ma temat parametru S.M.A.R.T 198 , tj. Offline Uncorrectable . Wychodzi na to, że część dysków nie resetuje go, nawet po pomyślnym przejściu testu offline. Za to demon smartd domyślnie ma ustawione informowanie o niezerowej wartości tego atrybutu w logu systemowym i prawdopodobnie chyba nie da się nic zrobić w tej sprawie ale można poinstruować smartd by wyrzucał komunikat tylko w przypadku gdy wartość tego atrybutu zostanie zwiększona w stosunku do wartości zapisanej przy poprzednim skanowaniu, czyli jeśli teraz mamy wartość, np. 2, to ostrzeżenie pojawi się gdy będzie tam widniało 3 i więcej.