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
|