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?

=== START OF INFORMATION SECTION ===
Model Family: Seagate BarraCuda 3.5
Device Model: ST4000DM004-2CV104
LU WWN Device Id: 5 000c50 0dcf290ca
Firmware Version: 0001
User Capacity: 4,000,787,030,016 bytes [4.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5425 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sun Oct 27 20:46:32 2024 +08
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 063 038 006 Pre-fail Always -
93564400
3 Spin_Up_Time 0x0003 097 096 000 Pre-fail Always -
0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always -
58
5 Reallocated_Sector_Ct 0x0033 099 096 010 Pre-fail Always -
1888
7 Seek_Error_Rate 0x000f 080 060 045 Pre-fail Always -
110321265
9 Power_On_Hours 0x0032 096 096 000 Old_age Always -
4003 (249 149 0)
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always -
0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always -
55
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 055 053 040 Old_age Always -
45 (Min/Max 41/46)
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 -
5086
194 Temperature_Celsius 0x0022 045 047 000 Old_age Always -
45 (0 30 0 0 0)
195 Hardware_ECC_Recovered 0x001a 080 064 000 Old_age Always -
93564400
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 -
2982h+05m+40.321s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline -
40983681830
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline -
98591148976

Error 1 occurred at disk power-on lifetime: 3216 hours (134 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 28 ff ff ff 4f 00 06:26:05.045 READ FPDMA QUEUED
60 00 e0 ff ff ff 4f 00 06:26:05.005 READ FPDMA QUEUED
60 00 78 ff ff ff 4f 00 06:26:04.983 READ FPDMA QUEUED
60 00 20 ff ff ff 4f 00 06:26:04.400 READ FPDMA QUEUED
60 00 20 ff ff ff 4f 00 06:26:04.400 READ FPDMA QUEUED

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 4003 -
# 2 Extended offline Completed: read failure 90% 3937
655698472

--
Marcin

do góry

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/seat
ools/
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ć...

do góry

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

do góry

On 2024-10-28, marrgol <m...@a...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/seat
ools/
> 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

do góry

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

do góry

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.

do góry