🚀 go-pugleaf

On 2024-10-28 at 05:04 Marcin Debowski wrote:
W Seagate'ach interpretacja wartości atrybutów SMART nie jest taka
oczywista.  Np. chyba gdzieś kiedyś czytałem, że atrybut Seek Error
Rate ma 48 bitów, z czego pierwsze 16 to liczba błędów, a pozostałe
32 to całkowita liczba operacji seek.  U ciebie 110321265 dziesiętnie
to na 48 bitach 000006935E71 hexadecymalnie, a to by oznaczało,
że w 110321265 ostatnich wykonanych operacjach seek było… 0 błędów.

Bardzo możliwe, że Raw Read Error Rate i Hardware ECC Recovered
interpretuje się podobnie, co nawet tłumaczyłoby, dlaczego te
liczby są równe (na wszystkich moich Seagate'ach te dwa atrybuty
też zawsze miały duże wartości i były równe) -- 0 błędów odczytu
i 0 korekcji tych błędów w tej samej liczbie operacji read
(ew. wszystkie błędy skorygowane, jeśli liczba i/lub podział bitów
atrybutu jest inny).

Ogólnie, jak dla mnie, te parametry chyba nie wyglądają tak źle; jedyną
niepokojącą rzeczą jest może liczba przemapowanych sektorów.  Ściągnij
sobie https://www.seagate.com/pl/pl/support/downloads/seatools/
i zrób na tym dysku 'Fix All', najlepiej kilka razy -- jeśli liczba
przemapowanych sektorów nie będzie rosnąć za każdym razem, i SeaTools
nie odradzą, to chyba można będzie go jeszcze poużywać…

On 10/28/24 4:04 AM, Marcin Debowski wrote:

> Mam Seagate'a jak poniżej, który mi pada w sposób jakiego wczesniej nie
> doświadczyłem. Dysk jest relatywnie młody, niezajechany, pracował
> wczesniej w macierzy zfs. Po pewnym czasie zfs zaczął sygnalizować
> błędy, podejmował próby naprawy, które kończyły się tym, że dysk znikał
> w ogóle jako urządznie. Restart hosta skutkował pojawieniem się urządzenia
> i pomyślnym odbudowaniem macierzy z tym dyskiem. W sumie dość klasyczny objaw
> problemów z okablowaniem. Ale to nie było to, - później meczyłem
> go bez okablowania (w obudowie NAS).

Nie żebym się czepiał, ale stwierdzenie "niezajechany" i "ZFS" w 
przypadku dysku DM-SMR to IMHO tak trochę się wyklucza... ;P

Dobra wiadomość jest taka, że wszystkie dyski DM-SMR tak mają i dlatego 
*NIE* używa się ich w macierzach.

Wrzuć go do jakiegoś desktopa i jeszcze parę lat pożyje.

Tu masz listę czego unikać
https://www.truenas.com/community/resources/list-of-known-smr-drives.141/

Jak masz więcej takich dysków to koniecznie monitoruj ich temperatury w 
trakcie intensywnych zapisów. Jeśli nie wzrasta drastycznie i ich żółwie 
tempo Ci nie przeszkadza to dramatu nie ma.


-- 
_____ __________________________
\`   Y   (__)  __\`  |  |  |  '/
  T  | |  |  |  \__T  =  |  !  T
  |__|_|__|__|_____|__|__|_____|  _  l  @  t l e n  .  p l

On 2024-10-28, marrgol <marrgol@address.invalid> wrote:
> On 2024-10-28 at 05:04 Marcin Debowski wrote:
> W Seagate'ach interpretacja wartości atrybutów SMART nie jest taka
> oczywista.  Np. chyba gdzieś kiedyś czytałem, że atrybut Seek Error
> Rate ma 48 bitów, z czego pierwsze 16 to liczba błędów, a pozostałe
> 32 to całkowita liczba operacji seek.  U ciebie 110321265 dziesiętnie
> to na 48 bitach 000006935E71 hexadecymalnie, a to by oznaczało,
> że w 110321265 ostatnich wykonanych operacjach seek było… 0 błędów.
>
> Bardzo możliwe, że Raw Read Error Rate i Hardware ECC Recovered
> interpretuje się podobnie, co nawet tłumaczyłoby, dlaczego te
> liczby są równe (na wszystkich moich Seagate'ach te dwa atrybuty
> też zawsze miały duże wartości i były równe) -- 0 błędów odczytu
> i 0 korekcji tych błędów w tej samej liczbie operacji read
> (ew. wszystkie błędy skorygowane, jeśli liczba i/lub podział bitów
> atrybutu jest inny).
>
> Ogólnie, jak dla mnie, te parametry chyba nie wyglądają tak źle; jedyną
> niepokojącą rzeczą jest może liczba przemapowanych sektorów.  Ściągnij
> sobie https://www.seagate.com/pl/pl/support/downloads/seatools/
> i zrób na tym dysku 'Fix All', najlepiej kilka razy -- jeśli liczba
> przemapowanych sektorów nie będzie rosnąć za każdym razem, i SeaTools
> nie odradzą, to chyba można będzie go jeszcze poużywać…

Sorry za poźną odpowiedź, ale chciałem to na spokojnie pozapuszczać, a 
trochę nie miałem sił/czasu.
 
No więc ten seagatowski test pokazuje takie same wyniki jak linuksowy 
smartmontools.
Dysk po przełożeniu do jeszcze innej maszyny (desktop, składak na B350) 
przestał powiększać liczniki błędów i przeszedł zarówno swój sprzętowy 
"long offline" jak i seagatowski general long. 

-- 
Marcin

On 2024-11-04, Michał Łukasik <michu_l@tlen_cut.pl> wrote:
> On 10/28/24 4:04 AM, Marcin Debowski wrote:
>
>> Mam Seagate'a jak poniżej, który mi pada w sposób jakiego wczesniej nie
>> doświadczyłem. Dysk jest relatywnie młody, niezajechany, pracował
>> wczesniej w macierzy zfs. Po pewnym czasie zfs zaczął sygnalizować
>> błędy, podejmował próby naprawy, które kończyły się tym, że dysk znikał
>> w ogóle jako urządznie. Restart hosta skutkował pojawieniem się urządzenia
>> i pomyślnym odbudowaniem macierzy z tym dyskiem. W sumie dość klasyczny objaw
>> problemów z okablowaniem. Ale to nie było to, - później meczyłem
>> go bez okablowania (w obudowie NAS).
>
> Nie żebym się czepiał, ale stwierdzenie "niezajechany" i "ZFS" w 
> przypadku dysku DM-SMR to IMHO tak trochę się wyklucza... ;P

On ma ca 170 dni power on, a ta macierz to w serwerze do backupów dla 
domowych multimediów - chodzi, jak zrzucam na niego kolejne kopie zdjęć 
/ płyt. Innymi słowy, to jest dziewica w wieku przedprodukcyjnym.

> Dobra wiadomość jest taka, że wszystkie dyski DM-SMR tak mają i dlatego 
> *NIE* używa się ich w macierzach.
>
> Wrzuć go do jakiegoś desktopa i jeszcze parę lat pożyje.

No tak właśnie zrobiłęm. Syn dostał :)

> Tu masz listę czego unikać
> https://www.truenas.com/community/resources/list-of-known-smr-drives.141/
>
> Jak masz więcej takich dysków to koniecznie monitoruj ich temperatury w 
> trakcie intensywnych zapisów. Jeśli nie wzrasta drastycznie i ich żółwie 
> tempo Ci nie przeszkadza to dramatu nie ma.

Mam jeszcze jednego takiego w tym zestawie i zasadniczo jak ceny są 
rozsądne to mając wybór kupuję cmr'y, ale ponieważ to nie jest macierz 
ani za często używana, ani z wymaganiami typu "performance", to nie 
przykładam do tego, aż takiej wagi.

-- 
Marcin

On 2024-11-08 at 23:48 Marcin Debowski wrote:
>> W Seagate'ach interpretacja wartości atrybutów SMART nie jest taka
>> oczywista.  Np. chyba gdzieś kiedyś czytałem, że atrybut Seek Error
>> Rate ma 48 bitów, z czego pierwsze 16 to liczba błędów, a pozostałe
>> 32 to całkowita liczba operacji seek. […]
I tak właśnie jest -- odszukałem w międzyczasie, gdzie to widziałem:
https://t1.daumcdn.net/brunch/service/user/axm/file/zRYOdwPu3OMoKYmBOby1fEEQEbU.pdf

Wykorzystując te informacje, jeśli wpiszesz do /etc/smart_drivedb.h
taki rekord:

  { "Seagate BarraCuda 3.5",
    "ST4000DM004-2CV104",
    "",
    "",
    "-v 1,hex56,Raw_Read_Error_Rate "
    "-v 7,hex48,Seek_Error_Rate "
    "-v 195,hex56,Hardware_ECC_Recovered"
  }

to dla tego modelu dysku smartctl będzie pokazywał raw values wymienionych
atrybutów heksadecymalnie.  Np. gdyby w 100000000 operacji Seek było
zero, jeden lub dwa błędy, smartctl standardowo pokazałby raw values
100000000, 4394967296 lub 8689934592, a z powyższym wpisem 0x000005F5E100,
0x000105F5E100 lub 0x000205F5E100 (dzięki temu widać zmianę tylko na dwóch
najstarszych bajtach określających liczbę błędów).

Albo, jeśli zamienić linie z '-v' na:

    "-v 1,raw24/raw32,Raw_Read_Error_Rate "
    "-v 7,raw24/raw32:z543210,Seek_Error_Rate "
    "-v 195,raw24/raw32,Hardware_ECC_Recovered"

może pokazywać jeszcze czytelniej, bo w formacie 'liczba błędów/liczba
operacji', czyli w przykładzie j.w. pokazałby 0/100000000, 1/100000000
lub 2/100000000.

On 2024-11-09, marrgol <marrgol@address.invalid> wrote:
> On 2024-11-08 at 23:48 Marcin Debowski wrote:
>>> W Seagate'ach interpretacja wartości atrybutów SMART nie jest taka
>>> oczywista.  Np. chyba gdzieś kiedyś czytałem, że atrybut Seek Error
>>> Rate ma 48 bitów, z czego pierwsze 16 to liczba błędów, a pozostałe
>>> 32 to całkowita liczba operacji seek. […]
> I tak właśnie jest -- odszukałem w międzyczasie, gdzie to widziałem:
> https://t1.daumcdn.net/brunch/service/user/axm/file/zRYOdwPu3OMoKYmBOby1fEEQEbU.pdf

Rekord przed modyfikacją:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   080   038   006    Pre-fail  Always       -       94033347
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       85
  5 Reallocated_Sector_Ct   0x0033   099   096   010    Pre-fail  Always       -       1888
  7 Seek_Error_Rate         0x000f   081   060   045    Pre-fail  Always       -       115218404
  9 Power_On_Hours          0x0032   096   096   000    Old_age   Always       -       4077 (248 217 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       82
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   099   099   000    Old_age   Always       -       1
188 Command_Timeout         0x0032   100   090   000    Old_age   Always       -       24 41 74
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   060   053   040    Old_age   Always       -       40 (Min/Max 32/40)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       43
193 Load_Cycle_Count        0x0032   098   098   000    Old_age   Always       -       5209
194 Temperature_Celsius     0x0022   040   047   000    Old_age   Always       -       40 (0 30 0 0 0)
195 Hardware_ECC_Recovered  0x001a   080   064   000    Old_age   Always       -       94033347
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       3040h+35m+26.635s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       40983957166
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       106428972707

> Wykorzystując te informacje, jeśli wpiszesz do /etc/smart_drivedb.h
> taki rekord:
>
>   { "Seagate BarraCuda 3.5",
>     "ST4000DM004-2CV104",
>     "",
>     "",
>     "-v 1,hex56,Raw_Read_Error_Rate "
>     "-v 7,hex48,Seek_Error_Rate "
>     "-v 195,hex56,Hardware_ECC_Recovered"
>   }

Po dodaniu powyższego:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   080   038   006    Pre-fail  Always       -       0x000000059ad5c3
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       85
  5 Reallocated_Sector_Ct   0x0033   099   096   010    Pre-fail  Always       -       1888
  7 Seek_Error_Rate         0x000f   081   060   045    Pre-fail  Always       -       0x000006de1843
  9 Power_On_Hours          0x0032   096   096   000    Old_age   Always       -       4077 (160 91 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       82
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   099   099   000    Old_age   Always       -       1
188 Command_Timeout         0x0032   100   090   000    Old_age   Always       -       103081902154
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   060   053   040    Old_age   Always       -       40 (Min/Max 32/40)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       43
193 Load_Cycle_Count        0x0032   098   098   000    Old_age   Always       -       5209
194 Temperature_Celsius     0x0022   040   047   000    Old_age   Always       -       40 (0 30 0 0 0)
195 Hardware_ECC_Recovered  0x001a   080   064   000    Old_age   Always       -       0x000000059ad5c3
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       3040 (26 173 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       40983957166
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       106428972707

> to dla tego modelu dysku smartctl będzie pokazywał raw values wymienionych
> atrybutów heksadecymalnie.  Np. gdyby w 100000000 operacji Seek było
> zero, jeden lub dwa błędy, smartctl standardowo pokazałby raw values
> 100000000, 4394967296 lub 8689934592, a z powyższym wpisem 0x000005F5E100,
> 0x000105F5E100 lub 0x000205F5E100 (dzięki temu widać zmianę tylko na dwóch
> najstarszych bajtach określających liczbę błędów).
>
> Albo, jeśli zamienić linie z '-v' na:
>
>     "-v 1,raw24/raw32,Raw_Read_Error_Rate "
>     "-v 7,raw24/raw32:z543210,Seek_Error_Rate "
>     "-v 195,raw24/raw32,Hardware_ECC_Recovered"
>
> może pokazywać jeszcze czytelniej, bo w formacie 'liczba błędów/liczba
> operacji', czyli w przykładzie j.w. pokazałby 0/100000000, 1/100000000
> lub 2/100000000.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   080   038   006    Pre-fail  Always       -       0/94033347
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       85
  5 Reallocated_Sector_Ct   0x0033   099   096   010    Pre-fail  Always       -       1888
  7 Seek_Error_Rate         0x000f   081   060   045    Pre-fail  Always       -       0/115218524
  9 Power_On_Hours          0x0032   096   096   000    Old_age   Always       -       4077 (178 13 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       82
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   099   099   000    Old_age   Always       -       1
188 Command_Timeout         0x0032   100   090   000    Old_age   Always       -       103081902154
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   060   053   040    Old_age   Always       -       40 (Min/Max 32/40)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       43
193 Load_Cycle_Count        0x0032   098   098   000    Old_age   Always       -       5209
194 Temperature_Celsius     0x0022   040   047   000    Old_age   Always       -       40 (0 30 0 0 0)
195 Hardware_ECC_Recovered  0x001a   080   064   000    Old_age   Always       -       0/94033347
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       3040 (44 95 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       40983957166
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       106428972707

Przy czym ten software Seagate'a raportuje wyniki według wersji 
pierwotnej i robi to nadal, co wskazuje, że nie korzysta ze 
smartmontools'ów. Nazwy konkretnych rekordów są odrobinę inne, ale 
semantycznie wydają się zbliżone.

-- 
Marcin

On Mon, 28 Oct 2024 04:04:47 GMT, Marcin Debowski wrote:

> Mam Seagate'a jak poniżej, który mi pada w sposób jakiego wczesniej nie
> doświadczyłem. Dysk jest relatywnie młody, niezajechany, pracował
> wczesniej w macierzy zfs. Po pewnym czasie zfs zaczął sygnalizować
> błędy, podejmował próby naprawy, które kończyły się tym, że dysk znikał
> w ogóle jako urządznie. Restart hosta skutkował pojawieniem się
> urządzenia i pomyślnym odbudowaniem macierzy z tym dyskiem. W sumie dość
> klasyczny objaw problemów z okablowaniem. Ale to nie było to, - później
> meczyłem go bez okablowania (w obudowie NAS).
> 
> badblocks pokazuje sporo uszkodzonych sektorów. Dysk nie przechodzi
> smart extended, ale przchodzi short. Nie daje akustycznych objawów
> typowych dla padających dysków mechanicznych (czkawka/rzeżenie przy
> próbie odczytów "bad'ów).
> 
> Wysokie Raw_Read_Error_Rate, z dokładnie taką samą wartością
> Hardware_ECC_Recovered. Wysokie Seek_Error_Rate. Offline_Uncorrectable
> 0. Current_Pending_Sector 0.
> 
> O co tu biega?

Pare osob odpisalo, ale nikt nie zauwazyl tego?
5 Reallocated_Sector_Ct   0x0033   099   096   010    Pre-fail  
Always        -       1888

1888 realokacji, ten dysk to trup. Jedyna (znana mi) nadzieja to SpinRite, 
ktory sprawi, ze jak sie wszystko uda to bedzie przechodzil long SMART 
test a takze nie bedzie sie wywalal z systemu czy z macierzy (bo zmapuje 
na sile wszystkie bady). Ale zaufany juz nigdy nie bedzie, bo bady z 
czasem pewnie beda przybywac w innych miejscach. Taki dysk tylko jako 
jakas dodatkowa kopia danych czy opchnac na internet jako uszkodzony/na 
czesci.


-- 
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

>> O co tu biega?
> 
> Pare osob odpisalo, ale nikt nie zauwazyl tego?
> 5 Reallocated_Sector_Ct   0x0033   099   096   010    Pre-fail
> Always        -       1888
> 
> 1888 realokacji, ten dysk to trup. Jedyna (znana mi) nadzieja to SpinRite,
> ktory sprawi, ze jak sie wszystko uda to bedzie przechodzil long SMART
> test a takze nie bedzie sie wywalal z systemu czy z macierzy (bo zmapuje
> na sile wszystkie bady). Ale zaufany juz nigdy nie bedzie, bo bady z
> czasem pewnie beda przybywac w innych miejscach. Taki dysk tylko jako
> jakas dodatkowa kopia danych czy opchnac na internet jako uszkodzony/na
> czesci.

A co dokładnie robi SpinRate? Oszukuje i kasuje smart czy coś realnie wykonuje?


-- 
szopen

On 2024-12-05, pioruns <www@com.pl> wrote:
> On Mon, 28 Oct 2024 04:04:47 GMT, Marcin Debowski wrote:
>
>> Mam Seagate'a jak poniżej, który mi pada w sposób jakiego wczesniej nie
>> doświadczyłem. Dysk jest relatywnie młody, niezajechany, pracował
>> wczesniej w macierzy zfs. Po pewnym czasie zfs zaczął sygnalizować
>> błędy, podejmował próby naprawy, które kończyły się tym, że dysk znikał
>> w ogóle jako urządznie. Restart hosta skutkował pojawieniem się
>> urządzenia i pomyślnym odbudowaniem macierzy z tym dyskiem. W sumie dość
>> klasyczny objaw problemów z okablowaniem. Ale to nie było to, - później
>> meczyłem go bez okablowania (w obudowie NAS).
>> 
>> badblocks pokazuje sporo uszkodzonych sektorów. Dysk nie przechodzi
>> smart extended, ale przchodzi short. Nie daje akustycznych objawów
>> typowych dla padających dysków mechanicznych (czkawka/rzeżenie przy
>> próbie odczytów "bad'ów).
>> 
>> Wysokie Raw_Read_Error_Rate, z dokładnie taką samą wartością
>> Hardware_ECC_Recovered. Wysokie Seek_Error_Rate. Offline_Uncorrectable
>> 0. Current_Pending_Sector 0.
>> 
>> O co tu biega?
>
> Pare osob odpisalo, ale nikt nie zauwazyl tego?
> 5 Reallocated_Sector_Ct   0x0033   099   096   010    Pre-fail  
> Always        -       1888

Zauważyło.

> 1888 realokacji, ten dysk to trup. Jedyna (znana mi) nadzieja to SpinRite, 
> ktory sprawi, ze jak sie wszystko uda to bedzie przechodzil long SMART 

On w tej chwili przechodzi long smart beż zadnych esktra zabiegów. Na 
samym poczatku, jak zaczeły się kłopoty, to było jakieś 53 relokowanych 
sektorów, a do tych 1888 powiekszyło się w wyniku późniejszych testów. 
Sprawa jest nadal dość tajemnicza bo od 15 listopada dysk jest nadal w 
użyciu a liczba sektorów się nie powiększa.

Nb. cały problem zaczął się tak, że zdjąłem serwer z szafy by dołożyc 
nowy dysk, przy czym ten akurat nie był wtedy ruszany. Kłopoty nadal 
występowały po przełożeniu dysku do obudowy na usb. To wtedy powiekszyło 
się do 1888. Po przełożeniu do desktopu syna pracuje stabilnie. Jedyne 
co mi prawdę mówiąc przychodzi do głowy, że to jakaś wada produkcyjna, w 
stylu paprocha, który zaczął latać w środku. Uszkodził co mógł i gdzieś 
się ponownie zakotwiczył.

-- 
Marcin

On Thu, 5 Dec 2024 11:16:51 +0100, szopen wrote:

>>> O co tu biega?
>> 
>> Pare osob odpisalo, ale nikt nie zauwazyl tego?
>> 5 Reallocated_Sector_Ct   0x0033   099   096   010    Pre-fail Always  
>>      -       1888
>> 
>> 1888 realokacji, ten dysk to trup. Jedyna (znana mi) nadzieja to
>> SpinRite,
>> ktory sprawi, ze jak sie wszystko uda to bedzie przechodzil long SMART
>> test a takze nie bedzie sie wywalal z systemu czy z macierzy (bo
>> zmapuje na sile wszystkie bady). Ale zaufany juz nigdy nie bedzie, bo
>> bady z czasem pewnie beda przybywac w innych miejscach. Taki dysk tylko
>> jako jakas dodatkowa kopia danych czy opchnac na internet jako
>> uszkodzony/na czesci.
> 
> A co dokładnie robi SpinRate? Oszukuje i kasuje smart czy coś realnie
> wykonuje?

Nic, czego long smart test nie powinien robic w teorii, ale nie robi. 
Spinrite realokuje wszystko niedobre co znajdzie na swojej drodze, i 
wywala z uzytku. Decyduje na podstawie nie tylko bledow odczytu, ale tez 
zapisu czy weryfikacji. Nie raz mialem taki dysk, ze mial bady, nie chcial 
przejsc long testu, a po Spinrite paru sesjach juz przechodzil.
Nawet mam taki dysk w kompie jeden, kupilem za grosze jako uszkodzony, 
zeskanowalem wszystkie bady, i smiga w RAID1, przechodzi wszelkie testy i 
nic nie spowalnia ani nie wywala bledow w systemie.

-- 
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

On Fri, 06 Dec 2024 11:21:29 GMT, Marcin Debowski wrote:

> On w tej chwili przechodzi long smart beż zadnych esktra zabiegów. Na
> samym poczatku, jak zaczeły się kłopoty, to było jakieś 53 relokowanych
> sektorów, a do tych 1888 powiekszyło się w wyniku późniejszych testów.
> Sprawa jest nadal dość tajemnicza bo od 15 listopada dysk jest nadal w
> użyciu a liczba sektorów się nie powiększa.
> 
> Nb. cały problem zaczął się tak, że zdjąłem serwer z szafy by dołożyc
> nowy dysk, przy czym ten akurat nie był wtedy ruszany. Kłopoty nadal
> występowały po przełożeniu dysku do obudowy na usb. To wtedy powiekszyło
> się do 1888. Po przełożeniu do desktopu syna pracuje stabilnie. Jedyne
> co mi prawdę mówiąc przychodzi do głowy, że to jakaś wada produkcyjna, w
> stylu paprocha, który zaczął latać w środku. Uszkodził co mógł i gdzieś
> się ponownie zakotwiczył.

W pierwszym poscie napisales ze nie przechodzi testu. Ale fajnie ze sie 
"naprawil". Zdolal zeskanowac swoje bady wszystkie i wylaczyc je. Jesli 
ilosc badow nie przybywa, zadne bledy sie nie pojawiaja, to moze jeszcze 
wycisniesz pare lat z niego w jakims RAIDzie. Ale skanuj go co jakis czas 
i sprawdzaj bady, bo moze sie posypac w przyszlosci.
No wady produkcyjne sie zdazaja, to loteria jak z kazda technika.

-- 
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

On 2024-12-08, pioruns <www@com.pl> wrote:
> On Thu, 5 Dec 2024 11:16:51 +0100, szopen wrote:
>
>>>> O co tu biega?
>>> 
>>> Pare osob odpisalo, ale nikt nie zauwazyl tego?
>>> 5 Reallocated_Sector_Ct   0x0033   099   096   010    Pre-fail Always  
>>>      -       1888
>>> 
>>> 1888 realokacji, ten dysk to trup. Jedyna (znana mi) nadzieja to
>>> SpinRite,
>>> ktory sprawi, ze jak sie wszystko uda to bedzie przechodzil long SMART
>>> test a takze nie bedzie sie wywalal z systemu czy z macierzy (bo
>>> zmapuje na sile wszystkie bady). Ale zaufany juz nigdy nie bedzie, bo
>>> bady z czasem pewnie beda przybywac w innych miejscach. Taki dysk tylko
>>> jako jakas dodatkowa kopia danych czy opchnac na internet jako
>>> uszkodzony/na czesci.
>> 
>> A co dokładnie robi SpinRate? Oszukuje i kasuje smart czy coś realnie
>> wykonuje?
>
> Nic, czego long smart test nie powinien robic w teorii, ale nie robi. 
> Spinrite realokuje wszystko niedobre co znajdzie na swojej drodze, i 
> wywala z uzytku. Decyduje na podstawie nie tylko bledow odczytu, ale tez 
> zapisu czy weryfikacji. Nie raz mialem taki dysk, ze mial bady, nie chcial 
> przejsc long testu, a po Spinrite paru sesjach juz przechodzil.
> Nawet mam taki dysk w kompie jeden, kupilem za grosze jako uszkodzony, 
> zeskanowalem wszystkie bady, i smiga w RAID1, przechodzi wszelkie testy i 
> nic nie spowalnia ani nie wywala bledow w systemie.

Takie rzeczy się zdarzają, ale jakoś cześciej chyba kiedyś, przynajmniej 
mi, zdarzały, bo dawno nie miałem takiego przypadku. Zwykle pomagało 
przejechanie dysku z zapisem. DD np. Wczesniej widać było po logach, że 
sypie błedami, dd nie znalazł żadnego (w trybie rw), ale po 
poszukiwaniach przestawał sypac.

-- 
Marcin

On 2024-12-08, pioruns <www@com.pl> wrote:
> On Fri, 06 Dec 2024 11:21:29 GMT, Marcin Debowski wrote:
>
>> On w tej chwili przechodzi long smart beż zadnych esktra zabiegów. Na
>> samym poczatku, jak zaczeły się kłopoty, to było jakieś 53 relokowanych
>> sektorów, a do tych 1888 powiekszyło się w wyniku późniejszych testów.
>> Sprawa jest nadal dość tajemnicza bo od 15 listopada dysk jest nadal w
>> użyciu a liczba sektorów się nie powiększa.
>> 
>> Nb. cały problem zaczął się tak, że zdjąłem serwer z szafy by dołożyc
>> nowy dysk, przy czym ten akurat nie był wtedy ruszany. Kłopoty nadal
>> występowały po przełożeniu dysku do obudowy na usb. To wtedy powiekszyło
>> się do 1888. Po przełożeniu do desktopu syna pracuje stabilnie. Jedyne
>> co mi prawdę mówiąc przychodzi do głowy, że to jakaś wada produkcyjna, w
>> stylu paprocha, który zaczął latać w środku. Uszkodził co mógł i gdzieś
>> się ponownie zakotwiczył.
>
> W pierwszym poscie napisales ze nie przechodzi testu. Ale fajnie ze sie 
> "naprawil". Zdolal zeskanowac swoje bady wszystkie i wylaczyc je. Jesli 
> ilosc badow nie przybywa, zadne bledy sie nie pojawiaja, to moze jeszcze 
> wycisniesz pare lat z niego w jakims RAIDzie. Ale skanuj go co jakis czas 
> i sprawdzaj bady, bo moze sie posypac w przyszlosci.
> No wady produkcyjne sie zdazaja, to loteria jak z kazda technika.

Problem, że się stan relokowanych przy tym nie zmienił (pomiędzy fail 
and pass). Nie do końca współgra to z teorią paprocha, ale i tak nie 
pozostaje nic innego, jak jeździć i obserwować.

-- 
Marcin