dynamic disk failed - sttátusz 100%

[tejminatoj]

A programot régóta és több példányban használom, jelzett felületi problémákat amivel volt elkerült adatvesztés, de van egy eset amit úgy néz ki nem tudok vele megelőzni.
Már sokadszor futok bele, hogy a win alatt használt összefűzött dinamikus diszkekből álló kötetek egyik HDD-je problémás lesz, ezzel az adott kötet failed-be megy át és nem elérhető.
A HDSentinel meg ettől függetlenül küldi a 100%-os státuszt, mert az hogy kiesett a hdd azt nem veszi észre így nem számít, a többivel meg pont nincs semmi baj.
Ez normális működés?

Most két nap után a sikertelen biztonsági mentési logokból lett gyanús hogy valami mégsem stimmel...
Nem lehetne valahogy kiszúrni hogy van a rendszerben egy failed kötet, és a státuszba beletenni?
Simán gondolom nem megy, mert akkor egy hordozható HDD üzemszerű lecsatlakozásánál visítozás lenne, de lehetne egy mező ahol a figyelendő kötetek beállíthatóak lennének, vagy a HDD-knél megadni hogy belső = figyelendő vagy nem.

A szép az hogy most kirobbantva a HDD-t brutális seektime-okat produkál bizonyos részeken - ami elég ahhoz, hogy egy összefűzött kötet failed-be menjen, viszont ennek ellenére azt mondja magáról a sekk test is meg a rövid önteszt is hogy 0 hiba.

Ha már itt tartunk, mennyire racionális, hogy egy másik azonos típusú HDD-nél egyszer csak 2-3 lépésben megjelent kb 300 pending szektor, majd néhány hét alatt nyom - relokáció - nélkül eltűnik?

[hdsentinel]

Természetesen nem normális működés, de nem igazán a HDSentinel tehet róla (sőt, valószínűleg nem is a merevlemez).
A 100%-os merevlemezek hirtelen kiesése, lecsatlakozása, problémája szinte minden esetben a környezettel kapcsolatos hibára vezethető vissza. Laza, lötyögős SATA adatkábel, kontakthibás tápkábel, tápellátás zavar, magas működési hőmérséklet (nem csak a HDD-é), túlhúzás - a leggyakoribb okok.

Egyébiránt a programban a Fájl menüben található Windows kötet/RAID információ pontosan ezért készült: az aktuális állapot ellenőrizhető vele (pl. ha a kötet sérült vagy rendben van). Ez természetesen a részletes riportba is opcionálisan bekerülhet (Beállítások -> Üzenet beállítások -> Részletes riport elemei dobozban legalul be lehet jelölni). Így az egyes riportok, amik probléma (vagy napi státusz jelentés) esetén küldésre kerülnek, tartalmazzák ezt az információt is.

Köszönöm a tippet! Jelenleg a Hard Disk Sentinel Enterprise változatában van erre lehetőség (naplózza a csatlakoztatott / kiesett / leválasztott eszközöket és kérhető riasztás is ilyen esetben). Lehetséges, hogy másik változat(ok)ba is be fog kerülni ez a funkció.

A szép az hogy most kirobbantva a HDD-t brutális seektime-okat produkál bizonyos részeken - ami elég ahhoz, hogy egy összefűzött kötet failed-be menjen, viszont ennek ellenére azt mondja magáról a sekk test is meg a rövid önteszt is hogy 0 hiba.

Gyanú esetén ennél sokkal több tesztet érdemes futtatni, amiket a program biztosít.
http://www.hdsentinel.hu/faq.php#test
Nem ártana a részletes önteszt is ill. a felület teszt (legalább az olvasás), amivel tényleg kiszűrhető ha a felületen bárhol probléma található és a teszt során ellenőrizhető az állapot-változás, átviteli sebesség, hőmérséklet-szint, amelyek alapján látható, ha tényleg probléma van.

Ha már itt tartunk, mennyire racionális, hogy egy másik azonos típusú HDD-nél egyszer csak 2-3 lépésben megjelent kb 300 pending szektor, majd néhány hét alatt nyom - relokáció - nélkül eltűnik?

Ha a környezettel van gond, akkor sajnos teljesen racionális, mivel az pontosan ilyen jellegű problémákat generál. Ilyenkor sok esetben a merevlemeznek nincs baja, erre utal, hogy további használat során (amikor a kérdéses terület felülvizsgálatra kerül) a szektorok állapota megjavul (nem kerül egyetlen szektor sem átallokálásra).

Esetleg ha a Riport menü Teszt riport küldése a fejlesztőnek opció használatával kapnék egy riportot, talán többet lehetne mondani az aktuális helyzet ismeretében.

[tejminatoj]

A javaslatnak megfelelően futtattam még további teszteket más gépre csatolva is. Hiba egyszer sem volt, csak durván pozitív irányba szőrös seek test eredmény. Aztán egyszer csak nem indult el többet a HDD. A garanciális bejelentésnek csere lett a vége.
Fura, mint írtam nem ez az első eset, hogy dinamikus diszkekből álló tömbök szétesése az első (és van hogy egyetlen) jele a közeledő HDD-halálnak. Persze a szétesést okozhatja a környezet is, de eddig a szétesés után viszonylag gyorsan - néhány napon / héten belül jött a végül garanciális cserét hozó motor vagy lemezfelületi hiba is.
Ebből nekem az áll össze, hogy a HDD gyártók által beírt S.M.A.R.T. adatokból nem feltétlenül lehet minden közeledő hibát kiszúrni. Hiába volt ennél a Samsungnál "Seek Error Rate" ill. "Seek Time Performance" bejegyzés azok értéke 0 volt a működés utolsó pillanatáig, más ide köthető adat - így név alapján - meg nincs.
Jelen esetben a kötet szétesés / HDD eltűnés mint másodlagos "jelzés" figyelése lehet az ami esetleg segíthet. Ha ez bele tud kerülni majd a "pro" verzióba is, az jó lesz, előre is köszönöm!

[hdsentinel]

Amikor a HDD elkezdett furcsán viselkedni (pl. azonnal amint kikerült a RAID-ből, amikor a teszt(ek) lefutottak, amikor a "szőrös" seek test eredmény kijött), jó lett volna, ha sikerül riportot küldeni a Riport -> Teszt riport küldése a fejlesztőnek opcióval a jelenség leírásával.
A helyzet ugyanis az, hogy a S.M.A.R.T. adatok egy része statisztikai információt hordot ezért nem kerülnek komoly súllyal figyelembevételre. De számos ilyen esetben sikerült összefüggést találni valódi meghibásodás és bizonyos értékek között, aminek következtében legközelebb már hamarabb lehetne jelezni a közelgő problémát.
Valóban, elvileg a jelzett attribútumokból lehetne következtetni a problémára, de megesik (pont a Samsung-nál volt ilyen több ízben), hogy egyéb attribútumok értékei (amiknek amúgy kevés jelentőséget tulajdonítana az ember) jeleztek előre katasztrófát.

Ehhez a beérkező riportok komoly segítséget nyújtanak, főleg bizonyos típusok, gyártók esetén. Teljesen hasonlóan, mint amikor pl. a vírusirtókban a "gyanús" eseteket be lehet küldeni elemzésre.

A S.M.A.R.T. értékek az esetek nagy többségében segítenek (megfelelő elemzés és értékelés esetén) de nem helyettesítik az időszakos adatmentést (backup).
Pontosan ezért van a Pro verzióban adatmentő modul és pont ezért biztosít a program számos olyan tesztet, amik ugyan figyelik a S.M.A.R.T. értékek változását, de azoktól független ellenőrzést biztosítanak. Gondolok itt pont a seek test-re és a Lemez pontból indítható felületi tesztekre, amiknek célja pontosan az, hogy a gyenge/hibás részt, ismeretlen eredetű teljesítménycsökkenést felderítsék, megjelenítsék. Ezek persze akkor is használhatóak, ha a S.M.A.R.T.-ot teljesen figyelmen kívül hagyjuk vagy csak egyszerűen nem érhetőek el (pl. olyan régebbi USB merevlemez esetén, ahol az USB chip nem támogatja a működési paraméterek lekérdezését).

A HDD leválasztása/csatlakozása mindenképpen be fog kerülni egy későbbi PRO változatba is.