Sata diszk meg tud gyógyulni? Vagy hazudik a s.m.a.r.t.?

Sziasztok,

múlt héten bejelzett a NAS-om, idézem:

Device: /dev/sda [SAT], 8 Currently unreadable (pending) sectors

A hdsentinel szerint:

HDD Device  0: /dev/sda
HDD Model ID : TOSHIBA DT01ACA300
HDD Serial No: Y48V3EJGS
HDD Revision : MX6OABB0
HDD Size     : 2861588 MB
Interface    : S-ATA Gen3, 6 Gbps
Temperature  : 37 °C
Highest Temp.: 41 °C
Health       : 95 %
Performance  : 100 %
Power on time: 1938 days, 8 hours
Est. lifetime: more than 100 days

Még aznap megrendeltem az új merevlemezt, ma reggel cseréltem ki, épp tart a RAID5 tömb újraépítése.

Az a fura, hogy a csere előtt újra megnéztem a hdsentinelt, és már 100%-osnak állította a diszket, ez hogy lehetséges? A zabbixom szerint kb 4 nap 10 órán át volt 95%-os, azóta meg 100%-os...

(ugyanezt tapasztaltam kb 5 évvel ezelőtt, amikor még 1,5 TB-os diszkekből állt a tömb, csak akkor lement egész 9%-ig a health, majd idővel 100%-ra visszaállt)

Hozzászólások

Gondolom reallokalasra kerultek a pending sectorok. Mindez kiderul a reszletes smart adatokbol.

Ezt kb tudtam, de mivel ez a legöregebb diszk a gépben, jobbnak láttam cserélni. A "hibás" meg megy az NVR-be, amibe az emlegetett "9%"-os diszk van, ami jó ideje ugye 100%-os :-)

A kérdésem az, hogy ez lenne a bevett szokás, hogy a statisztikát hamisítják? Mi van, ha az ember nem monitorozza, csak pár havonta lekérdezi? Azt fogja hinni, hogy tökéletes minden diszkje, aztán a nagy francokat. Általában ahol megjelenik pár bad sector, azt követni szokta még több is :-)

Mit ertessz az alatt, hogy statisztika hamisitas? Ha felvetodik a hiba eshetosege, akkor megjelnik a pending sector a smart tablazatban. Ha iras tortenik egy ilyen teruletre, akkor ellenorzest kovetoen vagy eltunik a pending jeloles (mert kiderult, hogy minden ok) vagy atcimzesre kerul a szektor (ekkor megjelenik a reallokalt a smart adatokban). A smart nem mond ilyen %-os health erteket. Ezt az erteket az adott szoftver fejlesztoje talalja ki, valami alapjan, igy az ertek ugralasat a szoftver fejlesztojen kell szamonkerni.

Szerkesztve: 2020. 09. 23., sze - 11:55

en olyat tapasztaltam, hogy kb 1.5 evig szekrenyben levo erosen hibas (sok badsector, nagyon sok uzemora, nem veletlen lettek leselejtezve) diskek javultak meg maguktol (annyira hogy az uzemora is nullazodott). gyanus hogy a smart adatokat is elfelejtette a sok szekrenyben toltott ido alatt :)

Hasonló eset:
Szerverben az egyik, majd később egy másik disken jelent meg 1 db badszektor amit a SMART is mutatott. A diszkek eltávolítása után a másik gépbe betéve hdparm paranccsal sikerült ráírni a badszektoros részre és a hiba a SMART-ból is eltűnt.
Később kiderült, hogy alaplaphibás lett a gép, mert előszőr a SATA portok látványosabban kezdtek el produkálni hibákat, majd később jöttek más anomáliák is.

https://onlinestream.live/ - A legtöbb magyar rádió és TV egy helyen!

A merevlemezeken néha adatmosást is kell végezni. Olvasod és újraírod. Előfordulhatott, hogy rosszul olvasta ki az adatot a szektorból, de újraírva már jó volt. A NAS-omon félévente 1x megy az adatmosás (adattisztítás).

A HD Sentinel Pro verziója tud olyat, hogy adatterület frissítés. Elméletileg akkor az egész lemez reallokálásra kerül. Nekem volt egy külső lemezem, leejtettem. Lett rajta néhányszáz gyenge/függő szektor. Egyszer végignyomtam ezt az opciót (ami eltartott kb. 2 napig) és utána újra 100% lett.

Egy ideje aztán szórakozott, nagyon belassult és néha IO error is volt. Ja, és leesett a kondíció 18%-ra. Ezután újra futtattam ezt a dolgot csak egymás után 2x. 5 napig tartott. Utána még nyomtam neki egy adatterület frissítés opciót (olvasás-írás-olvasás). Ezek után úgy tűnik, hogy most a lemez ugyanolyan gyorsa, mint amilyen előtte volt és nem jönnek random az I/O hibák, viszont a kondíció még mindig csak 24% és elméletileg vannak függő szektorok is. Nem értem én ezt :D

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Ez tényleg a smart adatokból, mint varázsgömbből jóslást előállító program hibája... De szoftver (firmware) hiba volt anno az is, hogy vmi. Intel alaplapon lévő raid-vezérlőre kötött SSD-ket adott mennyiségű írás után a vezérlő sorra kihajította a tömbből. A gép áramtalanítása/visszakapcsolása után meg simán hibátlannak látta mindet... (Aztán vett az üf. a kommersz desktop ssd helyett Intel SSD-t, és megszünt a hiba...)