Zfs wykrył, że dysk zwraca błędy odczytu. Zerknąłem do "smart'a"
i widzę, poza paroma błędami UNC, też coś takiego:

196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always -
2
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always -
50
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline -
35

Zaniepokoiło mnie to, gdyż jestem osobą wrażliwą.

Zapuściłem "long test".
# 2 Extended offline Completed: read failure 90% 17359 19939344
i jeszce raz.
# 3 Extended offline Completed: read failure 90% 17358 19939344

Podmieniłem dysk a tego biedaczka wsadziłem do innej maszyny i zacząłem
badać.

Zapuściłem mu badblocks z zapisem i tu nastąpiło pierwsze WTF, bo
przeszedł bez błędów.

Zerknąłem do smarta a tam
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always -
2
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always -
0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline -
40

No to ponownie long test.
# 1 Extended offline Completed without error 00% 17541 -

Gdyby nie to stado i to powiększające się tych Offline_Uncorrectable
przy stałej liczbie Reallocated_Event_Count to pomyślałbym sobie, ot,
jakiś blok się osłabił, został nadpisany, teraz już się daje czytać i
wszyscy szczęśliwi. A tak to nie jestem pewien jak to wszystko
interpretować.

--
Marcin

do góry

Wcale nie przypadkiem, dnia Tue, 11 Jan 2022 09:03:35 GMT
doszła do mnie wiadomość <HJbDJ.180161$onI5.83162@fx13.ams1>
od Marcin Debowski <a...@I...zoho.com> :
>Zfs wykrył, że dysk zwraca błędy odczytu. Zerknąłem do "smart'a"
>i widzę, poza paroma błędami UNC, też coś takiego:
>
>196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always -
2
>197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always -
50
>198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline -
35
>
>Zaniepokoiło mnie to, gdyż jestem osobą wrażliwą.
>
>Zapuściłem "long test".
># 2 Extended offline Completed: read failure 90% 17359
19939344
>i jeszce raz.
># 3 Extended offline Completed: read failure 90% 17358
19939344
>
>Podmieniłem dysk a tego biedaczka wsadziłem do innej maszyny i zacząłem
>badać.
>
>Zapuściłem mu badblocks z zapisem i tu nastąpiło pierwsze WTF, bo
>przeszedł bez błędów.
>
>Zerknąłem do smarta a tam
>196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always -
2
>197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always -
0
>198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline -
40
>
>No to ponownie long test.
># 1 Extended offline Completed without error 00% 17541 -
>
>Gdyby nie to stado i to powiększające się tych Offline_Uncorrectable
>przy stałej liczbie Reallocated_Event_Count to pomyślałbym sobie, ot,
>jakiś blok się osłabił, został nadpisany, teraz już się daje czytać i
>wszyscy szczęśliwi. A tak to nie jestem pewien jak to wszystko
>interpretować.

Dysk nie pracuje stabilnie, nadaje się tylko do kosza lub mało
krytycznych zastosowań.

do góry

wtorek, 11 stycznia 2022 o 03:03:38 UTC-6 Marcin Debowski napisał(a):
> Zfs wykrył, że dysk zwraca błędy odczytu. Zerknąłem do "smart'a"
> i widzę, poza paroma błędami UNC, też coś takiego:
>
> 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 2
> 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 50
> 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 35
>
> Zaniepokoiło mnie to, gdyż jestem osobą wrażliwą.
>
> Zapuściłem "long test".
> # 2 Extended offline Completed: read failure 90% 17359 19939344
> i jeszce raz.
> # 3 Extended offline Completed: read failure 90% 17358 19939344
>
> Podmieniłem dysk a tego biedaczka wsadziłem do innej maszyny i zacząłem
> badać.
>
> 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.


> Zerknąłem do smarta a tam
> 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 2
> 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
> 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 40
>
> No to ponownie long test.
> # 1 Extended offline Completed without error 00% 17541 -
>
> Gdyby nie to stado i to powiększające się tych Offline_Uncorrectable

Offline uncorrectable czasem sie dziwnie zachowuje. Zalezy od producenta i typu
/modelu dyska.

> przy stałej liczbie Reallocated_Event_Count to pomyślałbym sobie, ot,
> jakiś blok się osłabił, został nadpisany, teraz już się daje czytać i
> wszyscy szczęśliwi. A tak to nie jestem pewien jak to wszystko
> interpretować.
>
smart ma czasem niekonsekwentne zachowania.status pouklada.

Zapusc badblocks znowu, pusc jakies testy. Jak dysk zdycha to zobaczysz problemy i to
rosnaco. Jak po prostu trafil na slabszy obszar i zremapowal to bedzie stabilny.

Mam pare dyskow ktore badblocksami ustabilizowalem i dzialaja ok juz pare lat.

Nie zebym jakos specjalnie polecal ale tez nie widze przeciwwskazan jak masz/robisz
backupy.
I czasem trwa nieco zanim dysk sobie wewnetrznie

do góry

Wcale nie przypadkiem, dnia Tue, 11 Jan 2022 08:03:54 -0800 (PST)
doszła do mnie wiadomość
<a02b2026-2711-4036-a251-e3016748e0e4n@googlegroups.
com>
od ptoki <s...@g...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.

do góry

wtorek, 11 stycznia 2022 o 11:46:55 UTC-6 a...@p...com napisał(a):
> Wcale nie przypadkiem, dnia Tue, 11 Jan 2022 08:03:54 -0800 (PST)
> doszła do mnie wiadomość
> <a...@g...com>
> od ptoki <s...@g...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.

do góry

On 2022-01-11, ptoki <s...@g...com> wrote:
> wtorek, 11 stycznia 2022 o 11:46:55 UTC-6 a...@p...com napisał(a):
>> Wcale nie przypadkiem, dnia Tue, 11 Jan 2022 08:03:54 -0800 (PST)
>> doszła do mnie wiadomość
>> <a...@g...com>
>> od ptoki <s...@g...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.

--
Marcin

do góry

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 <a...@I...zoho.com> :
>On 2022-01-11, ptoki <s...@g...com> wrote:
>> wtorek, 11 stycznia 2022 o 11:46:55 UTC-6 a...@p...com napisał(a):
>>> Wcale nie przypadkiem, dnia Tue, 11 Jan 2022 08:03:54 -0800 (PST)
>>> doszła do mnie wiadomość
>>> <a...@g...com>
>>> od ptoki <s...@g...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.

do góry

wtorek, 11 stycznia 2022 o 20:02:50 UTC-6 a...@p...com napisał(a):

> >Innymi słowy w zasadzie nic nie wiadomo poza tym, że coś się dzieje.

Nieco wiadomo, ale odpisuje nie temu przedpiscy wiec prosze o rozwage.
Wiadomo ze bledy sie pojawily i kontroler je adresuje naprawiajac.

> 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.

Tak, dziekuje za skrecyzowanie ze to nie tak ze jak sie na liscie 197 sektor pojawi
to juz jest nie do uratowania.
Ale troche sie przyczepie ze takie zachowanie nie jest sztywne, jeden producent zrobi
tak ze sprobuje zapisu a drugi od razu sektor zrealokuje.
W sumie to juz dzis ich na tyle niewielu zostalo ze moze nawet nie ma co roztrzasac
mozliwosci.

Ilu ich jest? Seagate, WD, Toshiba (oni chyba tylko rebranduja WD oidp)?

> 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.

I tu tez sie nieco nie zgodze.
Przyczyny dla jakich sektory sie uszkadzaja moga byc podobne do tych wykrytych w
fabryce albo w pierszych tygodniach pracy i te nie beda sie lawinowo mnozyc.
Takich bledow na dyskach moze byc calkiem sporo jak dysk sluzy tylko do zapisu (np.
logi albo materialy wideo nagrywane w kolko i nie odczytywane zbytnio.

Natomiast bledy powstale z powodu zanieczyszczen, utleniania sie powlok magnetycznych
czy jakichs urazow mechanicznych moga powodowac lawinowe narastanie liczby
uszkodzonych sektorow i w rezultacie pad dysku.

Wiec ja bym podsumowal to tak ze jak padlo pare sektorow na relatywnie intensywnie
uzywanym dysku w ciagu paru miesiecy to nie jest to duzo gorsza oznaka od po prostu
nowego dysku gdzie tych realokowanych raportowanych w smarcie juz troche jest.
Natomiast jak smart relatywnie czesto raportuje nowe uszkodzenia to rzeczywiscie,
trzeba sie z dyskiem pozegnac, magnesy i lozyska wyjac a reszte bezpiecznie wyrzucic.
No, albo ontrackowi sprzedac elektronike jak sie oglosza...

do góry

Czy da się orientacyjnie sprawdzić duży dysk w krótkim czasie?
Powiedzmy kupujemy od kogoś HDD 5TB, odbieramy osobiście i na miejscu podłączamy do
szybkiego testu (kilkanaście minut).

do góry

Wcale nie przypadkiem, dnia Wed, 12 Jan 2022 11:34:50 +0100
doszła do mnie wiadomość <61deaecb$0$528$65785112@news.neostrada.pl>
od ąćęłńóśźż <...@...pl> :
>Czy da się orientacyjnie sprawdzić duży dysk w krótkim czasie?
>Powiedzmy kupujemy od kogoś HDD 5TB, odbieramy osobiście i na miejscu podłączamy do
szybkiego testu (kilkanaście minut).

Nie da się, czasami potrzeba kilku/nastu cykli zapisu/odczytu
wszystkich sektorów, to może zająć kilka dni czy nawet tygodni pracy,
dodatkowo, można śledzić czas dostępu do pojedynczych sektorów, zrobić
listę tych z największym czasem dostępu i pomęczyć te sektory setkami
czy tysiącami cykli zapisu/odczytu.
Jest niby wbudowany w firmware short test, ale skuteczność może być
bardzo niska.
Jak kupujesz dysk, to kup z możliwością zwrotu do np 2-ch tygodni i
męcz go intensywnie cyklami erase/read(tak z osiem razy).

do góry