Wcale nie przypadkiem, dnia Wed, 12 Jan 2022 00:42:14 GMT
doszła do mnie wiadomość <GtpDJ.41446$Imt7.20696@fx09.ams1>
od Marcin Debowski <agatek@INVALID.zoho.com> :
>On 2022-01-11, ptoki <sczygiel@gmail.com> wrote:
>> wtorek, 11 stycznia 2022 o 11:46:55 UTC-6 ansaj...@polbox.com napisał(a):
>>> Wcale nie przypadkiem, dnia Tue, 11 Jan 2022 08:03:54 -0800 (PST)
>>> doszła do mnie wiadomość
>>> <a02b2026-2711-4036...@googlegroups.com>
>>> od ptoki <sczy...@gmail.com> :
>>> >wtorek, 11 stycznia 2022 o 03:03:38 UTC-6 Marcin Debowski napisał(a):
>>>
>>> >> Zapuściłem mu badblocks z zapisem i tu nastąpiło pierwsze WTF, bo
>>> >> przeszedł bez błędów.
>>> >>
>>> >Jest tak jak ma byc.
>>> >197 ci spadlo bo dysk sobie zrealokowal pending sectors.
>>> >
>>> No nie do końca, jak by zreallokował, to by wskoczyły do reallocated
>>> sectors.
>>> Do 197 trafiają sektory z błędnym odczytem danych(procedury wewnętrzne
>>> nie potrafiły tego skorygować), jednak zapis do takiego sektora się
>>> powiódł i sektor został na miejscu. Coś musiało spowodować taki błąd i
>>> jest wielce prawdopodobne, że to się znowu stanie za jakiś czas,
>>> loteria.
>>
>> No nie do konca.
>> 197 to sektory czekajace na przemapowanie. One nie beda juz reuzyte. A
>> przynajmniej nie w oficjalnej onterpretacji. Co se tam producent zrobil to
>> inna inkszosc.
>> Czyli po zapisie beda juz w innym miejscu. Wyzerowane 197 to znak ze dysk
>> nie powinien juz miec bledow odczytu i tak sie stalo. To oczekiwana reakcja
>> po badblocksach z zapisem.
>>
>> To ze sektory padaja to loteria ale nie znaczy ze ruszy lawina. Tak
>> jak pisalem, mam pare dyskow ktore wg coponiektorych powinny znalezc
>> sie w smieciach a dzialaja wesolo i bezproblemowo od lat.
>
>No właśnie to chyba mój pierwszy taki przypadek, że dysk mi się sypie
>jakoś łagodnie. Zwykle idzie to lawinowo, lub od razu zdechł pies.
>
>Nb. odnosnie dyskusji, tam w zasadzie jest napisane
>"Reallocated_Event_Count" a nie ilość bloków/sektorów. Nie wiemy
>(wiemy?) jak to dysk liczy i co np. kończy takie zdarzenie. Więc te
>Offline_Uncorrectable to może spokonie się mieścić w 2ch takich "event".
>
>Innymi słowy w zasadzie nic nie wiadomo poza tym, że coś się dzieje.
Sprawa jest prosta, dysk ma dwie tabele reallokowanych sektorów,
"fabryczne" - P-List i powstałe u usera końcowego G-List.
Jeśli jakiś sektor zostanie reallokowany u usera, to musi trafić do
G-List, nie ma w dyskach innej, "tajnej" tabeli na takie sektory,
translator musi znać nowe adresy sektorów po podmianie.
197 to sktory, które odczytują się z błędem i algorytm korekcji nie
może tego błędu naprawić, mogą sobie tkwić w takim stanie do usranej
znaczy się usłanej różami całkowitej śmierci dysku.
Naprawa polega na zapisie do takiego sektora i weryfikacji, jak się
zweryfikuje poprawnie, to sektor nie jest reallokowany, jak znów jest
błąd, to sektor trafia do G-List w której też zapisywany jest adres
sektora zamiennego.
Takie sektory nie powstają bez powodu, ich obecność może świadczyć o
kłopotach z nośnikiem czy innych problemach, dysk przestaje być
"zaufany" i moim zdaniem powinien zostać objęty wcześniejszą
emeryturą, ewentualnie można go stosować jako magazyn na mniej ważne
dane.
Victoria i MHDD dają sobie radę w naprawie takich sektorów bez
ruszania reszty danych na dysku.
|