Trafiłem na dysk (160GB Hitachi Deskstar T7K250, mający przepracowane
69044 godziny), który miał problemy z odczytem. Windows w pewnym
momencie, w trakcie normalnej pracy, stracił widoczność jednej z jego
partycji ("menedżer dysków", czy jak to tam się nazywa, widział tylko
jedną partycję - o prawidłowym rozmiarze - i wolne miejsce, w
rzeczywistości na dysku były dwie partycje typu MS-DOS z NTFS-em,
łącznie zajmujące 100% dysku).

S.M.A.R.T w tym momencie (po reboocie do GRML-a) pokazał następujące
surowe wartości:

5 Reallocated_Sector_Ct = 5
196 Reallocated_Event_Count = 5
197 Current_Pending_Sector = 6

Linuksowy fdisk bez problemu zobaczył obie partycje, a filesystemy
udało się podmontować i odczytać wszystkie pliki (dane na obu
partycjach zajmowały w sumie około 50-60% powierzchni dysku).

GNU ddrescue w pierwszym podejściu odczytało prawie całą zawartość
dysku - poza 4096B (nie pamiętam już dokładnie gdzie te problemy były,
ale gdzieś w okolicach 140GB). W drugim podejściu ddrescue poradziło
sobie jednak z tymi 4KB, których za pierwszym razem odczytac mu się
nie udało.

Po tej operacji atrybuty odrobinę się zmieniły:
5 Reallocated_Sector_Ct = 6
196 Reallocated_Event_Count = 6
197 Current_Pending_Sector = 6

Odczytałem jeszcze jednokrotnie całą zawartość dysku - już bez żadnego
problemu. Długi test S.M.A.R.T również przeszedł wtedy bez problemu.
Natomiast sektory wisiały nadal w stanie "pending" (atrybuty jak
powyżej = 6,6,6).

Dopiero nadpisanie całego dysku zerami spowodowało, że atrybuty
wyglądają tak, jak się tego spodziewałem po bezproblemowym odczytaniu
całej zawartości:
5 Reallocated_Sector_Ct = 6
196 Reallocated_Event_Count = 6
197 Current_Pending_Sector = 0

Do tej pory przekonany byłem, że "pending sectors" to są te, których
dysk nie potrafi odczytać i zostaną przemapowane przy najbliższym
zapisie. Tu jednak był już w stanie je odczytać i jak rozumiem
zremapował - po udanym odczycie przez ddrescue.

Dlaczego zatem z "pending" zniknęły dopiero po zapisie?


--
Jacek Politowski