główna strona
wróć
S.M.A.R.T Atrybut #05 - Retired/Reallocated Block Count - Ilość realokowanych sektorów
Ostatnia zmiana: 18.10.2016, Autor artykułu: Waldemar Miotk
artykul-0094.jpg

Atrybut #05 - Retired Block Count lub Reallocated Block Count lub Reallocated Sector Count to jeden z najważniejszych atrybutów obsługiwanych przez prawie wszystkie dyski twarde, zarówno mechaniczne jak i SSD. Nazwa po polsku to Ilość realokowanych sektorów/bloków.

Aby dokładniej wyjaśnić jak odczytywać wartości tego atrybutu muszę, przynajmniej w skrócie, opisać pewien mechanizm zaimplementowany we wszystkich współczesnych dyskach twardych.

Informacje na nośnikach komputerowych nie są zapisywane w sposób liniowy, ciągły, a odbywa się to w pewnych pakietach danych, zwanych sektorami. Pliki podzielone na mniejsze porcje zapisywane są zazwyczaj w kilku lub większej ilości sektorach. Sektory mogą być wielkości od 512 bajtów do aż 64kb. W związku z tym niewielki plik o wielkości 100 bajtów zostanie zapisany w jednym bloku 512 bajtowym, natomiast plik o wielkości 600 bajtów w dwóch sektorach każdy po 512 bajtów. Oczywiście jeżeli sektory mają po 4kb, to najmniejszy plik zajmie jeden cały sektor o wielkości 4kb (jest to opis uproszczony dla potrzeb tego wpisu).

W przypadku uszkodzenia nośnika, co czasami się zdarza, sektor nie może zostać zapisany. W takim przypadku dysk twardy oznacza taki sektor jako uszkodzony (bad sector lub bad block) i zastępuje go innym, umieszczonym w specjalnym, zarezerwowanym miejscu na dysku. Ilość takich zastąpień podawana jest przez Atrybut #05 mechanizmu S.M.A.R.T.

Oczywiście, idealnym rozwiązaniem byłoby, gdyby dysk twardy nie miał uszkodzonych sektorów i nie musiał wykonywać tej operacji. Tak wygląda idealny stan tego atrybutu dla dysku SSD:

SanDisk SDSSDA240G 240GB

A tak to wygląda dla dysku mechanicznego:

Seagate ST3000DM001 3TB

Niestety czasami może zdarzyć się coś niespodziewanego i sektor może ulec uszkodzeniu, na przykład na skutek uderzenia głowicy w talerz podczas pracy. O ile głowica takie coś przetrwa to na nośniku może ona odcisnąć swój ślad i spowodować uszkodzenie kilku sektorów. Dysk poradzi sobie z tym problemem wymieniając sektory uszkodzone z puli sektorów rezerwowych. I to akurat nie byłoby niczym strasznym a wręcz można powiedzieć, że dysk sam się naprawił. Problem natomiast występuje wtedy, gdy ilość realokowanych sektorów rośnie bez żadnej wiadomej przyczyny lub w skutek uderzenia głowicy nośnik uszkodził się tak bardzo, że się poważniej zarysował co może spowodować dalsze uszkodzenia. Oznacza to tylko jedno. Powłoka talerzy na której zapisywana jest nasza informacja ulega powolnemu zniszczeniu. Oto przykład nie tragiczny jeszcze, ale w stadium początkowym:

Seagate ST3160827AS 160GB

Nie jest tutaj jeszcze bardzo źle, gdyż próg nie został przekroczony ale można przypuszczać, że ilość tych sektorów będzie się zwiększała. Jeżeli nie, jeżeli pozostanie na tym poziomie, to nic się z dyskiem jeszcze nie stało i powinien pracować prawie idealnie. Trzeba to jednak monitorować. A dlaczego? Popatrzmy na ten sam dysk po pewnym czasie pracy (niecałe 2h):

ST3160827AS 160GB BAD SECTORS

Ilość realokowanych sektorów wzrosła do [HEX]202 czyli do [DEC]514. A wcześniej było to [HEX]154 czyli [DEC]340. Stan tego dysku pogarsza się i to dosyć szybko. Czas na zabezpieczenie danych i wymianę dysku.

Zobaczmy przykład tego Maxtora:

Maxtor 6Y080L0-80GB

Tutaj ilość realokowanych sektorów to już [HEX]62C czyli [DEC]1580. Może się robić niebezpiecznie, chociaż próg nadal nie został przekroczony, więc przynajmniej teoretycznie nie ma się czego obawiać.

W momencie gdy ilość realokowanych sektorów jest znaczna, to najwyższy czas na wymianę dysku. Obszar rezerwowy nie jest nieskończony i w końcu się zapełni. Na dodatek im więcej takich przeniesionych danych, tym dysk pracuje wolniej, gdyż głowica musi sięgać do dodatkowego obszaru za każdym razem, gdy napotka sektor przeniesiony. Nie warto zatem czekać na przekroczenie progu wyznaczonego przez producenta jeżeli ilość przeniesionych sektorów jest znaczna.

Bliższe informacje o mechanizmie S.M.A.R.T znajdziesz TUTAJ

Informacje o poprzednim atrybucie S.M.A.R.T #04 znajdziesz TUTAJ

Informacje o następnym atrybucie S.M.A.R.T #06 znajdziesz TUTAJ

 

 

Komentarze(0)

Podpis:
W celu potwierdzenia, zaznacz pole pod znakiem: D
Capcha
(c)2007-2016 Waldemar Miotk - ostatnia aktualizacja silnika 06.02.2016 - Twój IP: 52.200.130.163. Ta strona, aby lepiej działać, używa plików cookie przechowywanych na komputerach użytkowników. Wszystkie prawa do tekstów zamieszczonych na stronie są zastrzeżone, chyba że przy konkretnym tekście znajduje się inna informacja.
go up