Van e arra lehetoseg hogy kinyerjunk a vinyobol adatot arra nezve, volt e valamilyen irasi-olvasasi hiba. Ami soha nem jutott felhasznaloi szintre. Igy esetleg fel lehet keszulni adatvesztesre, megelozesre. :roll:
Laptop-ot hasznalok igy ott kiemelten elofordulhat ilyen.
Valaki azt tanacsolta hogy vegleges adatvesztes eseten erdemes megprobalni a vinyot lehuteni es egy probat tenni.
:lol:
[quote:e2c71ea189="monas"]Van e arra lehetoseg hogy kinyerjunk a vinyobol adatot arra nezve, volt e valamilyen irasi-olvasasi hiba. Ami soha nem jutott felhasznaloi szintre. Igy esetleg fel lehet keszulni adatvesztesre, megelozesre. :roll:
Ha smart jól van megcsinálva a konkrét vinyóban, akkor az pont arra való. A raw value-kat kell nézni:
1 Raw_Read_Error_Rate
5 Reallocated_Sector_Ct
195 Hardware_ECC_Recovered
az 1-es és 195-ösből, normális üzem közben mondjuk 1 év használat alatt 1-2000 darab normális. (Kivéve a seagate-eknél, mert ott rejtélyes módon több tíz milliót jeleznek a teljesen hibátlanul működö darabok is. Több 10 darab fordult már meg nálam a 7200.X-es szériákból, az összes ilyen volt, annak ellenére, hogy vadonat újak voltak. Vagy típushiba, vagy pedig a seagate valami teljesen más értelmezést adott a számoknak.)
Az 5-ösől több év használat során lehet 1-2 darab. Ha ezek szaporodnak, akkor kell nagyon sürgősen biztonsági másolatot csinálni. A smartd-t be lehet állítani, hogy riasszon, ha ez emelkedik. Alapból mindenre riaszt, vicces dolog látni a logokban, a temperature_celsius changed from 41 to 42 bejegyzéseket. :)
Valaki azt tanacsolta hogy vegleges adatvesztes eseten erdemes megprobalni a vinyot lehuteni es egy probat tenni.
:lol:
Hát az attól függ mi a hiba. Van amikor segít, van amikor kifejezetten ez teszi tönkre, és sajnos nincs rá általános szabály, hogy mikor melyik. A páralecsapódás nagy ellensége a vinyóknak, márpedig a lehűtésnél ez könnyen előfordul. A lemez és a fej között annyira kicsi a rés, hogy a páraréteg sokkal vastagabb annál. Egyszer kipróbáltam egy régi rossz mfm vinyóval (pedig ott még a maiaknál sokkal nagyobb légrés volt). Alapból simán forgott a lemez benne, mikor finoman ráleheltem azonnal megszorult és keményen befékeződött! Mihelyt elpárolgott a lemez azonnal újraindult, de utána látni lehetett egy finom karcolást ott ahol fej megszorult. Elég durva...
A gyártóknak egyébként is van egy elég szigorú előírása a maximális hőváltozási sebességre, azt hiszem olyan 5 C/10perc vagy valami hasonló üzem közben, és 10 C/10perc kikapcsolt állapotban. Namost ha hidegen indítják el, akkor könnyen lehet, hogy saját maga gyorsabban melegszik fel. Ez általában nem szokott baj lenni, kivéve a régebbi sokat szidott quantum lct szériát, na azokat nagyon könnyen meg lehet ezzel ölni.
Nekem adatmentésnél pont az szokott segíteni, ha üresen járatom és hagyom felmelegedni normális üzemi hőmérsékletre és csak ezután próbálok meg olvasni róla. Ettől még lehet, hogy tényleg segít a lehűtés is bizonyos esetekben, elég sok helyről hallottam már ilyet, csak óvatosan kell csinálni.
[quote:aba56e26ae="XMI"]
Ha smart jól van megcsinálva a konkrét vinyóban, akkor az pont arra való. A raw value-kat kell nézni:
1 Raw_Read_Error_Rate
5 Reallocated_Sector_Ct
195 Hardware_ECC_Recovered
az 1-es és 195-ösből, normális üzem közben mondjuk 1 év használat alatt 1-2000 darab normális.
Van ket ibm vinyom raid-ben par eve az itthoni gepben. Kicsit furak lettek az eredmenyek
Az egyiknel van raw_read_error_rate, 65536, ami ugye 2 hatvanya pont.., es nulla reallocated, a masiknal 0 a raw_read_error, es van hozza 6 athelyezett.
A kb 4-5 eves ibm-re mindketto 0.
A laptopban kb 1 eves ibm szinten 0/0
Ezek lehetnek realis ertekek?
egyébként nállam egy Maxtor 4R080L0-asnál nincs
Raw_Read_Error_Rate, a Reallocated_Sector_Ct az zérus, és a
Hardware_ECC_Recovered meg 26788. a winyó 121 órát futott
most akkor mi van?
egyébként a másik Maxtor 6E040L0-esemnél sincs 1-es, az 5-ös 0, a
195-ös meg 1185. ez már 190 óránál tart.
miért nincs Raw_Read_Error_Rate az egyiknél sem?
egyébként satás winyókra van valami hasonló trükk mint a smart az atákra?
Az en vinyom ezt kopi ki, zt3000 HP noteboot, 9 honapos, segitsetek ezt ertelmezni:
Location IDE eszköz A
Drive size 56 GB
Make and model FUJITSU MHT2060AT PL
Supports SMART? Igen
SMART enabled? Igen
Errors logged 1 errors detected
Passed drive check? Igen
Offline data collection status Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline data collection 440 seconds.
Offline data collection capabilities SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability Error logging supported.
No General Purpose Logging support.
Short self-test routine recommended polling time 2 minutes.
Extended self-test routine recommended polling time 60 minutes.
Conveyance self-test routine recommended polling time 2 minutes.
Raw Read Error Rate 64689
Throughput Performance 21758291
Spin Up Time 0
Start Stop Count 2537
Reallocated Sector Ct 8589934592000
Seek Error Rate 3337
Seek Time Performance 0
Power On Hours 11565549
Spin Retry Count 0
Power Cycle Count 972
Power-Off Retract Count 60
Load Cycle Count 27044
Temperature Celsius 43
Hardware ECC Recovered 136
Reallocated Event Count 285736960
Current Pending Sector 0
Offline Uncorrectable 0
Multi Zone Error Rate 11075
Run Out Cancel 2628549935473
Ha smart jól van megcsinálva a konkrét vinyóban, akkor az pont arra való. A raw value-kat kell nézni:
1 Raw_Read_Error_Rate
5 Reallocated_Sector_Ct
195 Hardware_ECC_Recovered
[quote:9ca620d50a="ricsip"]XMI: köszi a kimerítő :) válaszokat, ezt akár wiki-be is átkoppizhatnád!
Jaj, ahhoz előbb helyesírásilag, meg megfogalmazásilag rendbe kellene raknom, és most nagyon nincs kedvem hozzá. Meg a másik az, hogy ami értékeket én körülbelül saccra beírtam, azoknak ténylegesn utána kellene nézni a gyártó doksijában (rég olvastam már nagyon), mert a wiki-t azért komoly referenciaként is használják sokan.
Majd esetleg egy kicsit később, vagy ha valaki érez rá ihletet most, akkor szívesen átadom a jogot neki.
Ami pedig a konkrét kérdéseket illeti:
Sajnos nem vagyok se orákulum, se pedig Kürti Sándor, hogy ismerjem a gyárók egyéni hülyeségeit. A közelmúltban maxtort és seagate-et láttam viszonylag sokat, ezekről tudok úgy-ahogy nyilatkozni.
Maxtoréknál tényleg nincs Raw_read_error rate, ezt én is észrevettem. Ezen kívül náluk az üzemóra számláló 49 nap (2^32sec, ~1193 óra) után körbefordul! (Igen, így aztán az égegyadta világon semmi értelme nincsen.)
A 8589934592000 pedig 2^33*1000. Ennyi blokk biztos nincs a lemezen összesen, lehet, hogy a -1-et ábrázolják így. Azt, hogy mi a jelentése csak a gyártó tudná megmondani, ha akarná. Ja igen a smartmontools egyébként rengeteg gyártó-specifikus kódot tartalmaz, tehát ha hülyeségnek látszó értéket ad vissza, akkor meg kell próbálni újabb verziót, hátha ott már támogatva van a konkrét típus.
Az egész smartnak egyébként pont ez a halála. Minden gyártó egy saját maga által választott részhalmazát implementálja és egyéni értelmezést ad a számoknak. A rendes érték (tehát nem raw), ennek a kiküszöbölésére van, de itt is vannak eltérések. A maxtornál pl alapból 255-ről (némelyik meg 200-ról) indul , a seagate-nél jellegzetesen 100-ról. Elvileg akkor van gáz, ha az érték a treshold alá megy. Csakhogy én több olyan haldokló vinyót is láttam, ahol még súlyos adatvesztés után sem ment le az érték a treshold alá (pedig a raw value-kból látszott, hogy baj van). Ezért kell jobb híján a raw értékeket nézni, feltéve, hogy értelmes adatot ad vissza.
Talán az lehet az oka, hogy nem akarnak false positive riasztást, mert akkor sok felesleges garanciális csere lenne. Az más kérdés, hogy egy false negative viszont adatvesztéssel jár, és a felhasználó szemszögéből ez nagyobb gáz.
[quote:fdb790ab9f="XMI"]Az 5-ösől több év használat során lehet 1-2 darab.
Öhm. Most néztem meg (maxtor 4d040h2) és 63-at mutat. Ez akkor most azt jelenti, hogy ideje lesz bevásárolni. Még szerencse, hogy nekiálltam itt olvasgatni az éjszaka közepén. :D
Nemely, foleg regebbi BIOS tud lowlevel formatot. Viszont ezt _tilos_ haznalni, mert tobbet artasz vele, mint hasznalsz. En olyat olvastam, hogy ugyebar a cylinderek nem egyforma hosszuak, igy ami kozelebb van a lemez szelehez, oda tobb adatot lehet tenni. Erre eleg bonyolult algoritmus van, amit a gyarto nem mond meg. Viszont a BIOS-os lowlevel formatnal ha minden igaz, minden cylinderen ugyanannyi adat lesz, igy csokken a winyo kapacitasa, es allitolag mas tekintetben is rossz. Max akkor erdemes vele kiserletezni, ha a winyo abszolut nem mukodik, vagy a fele badsector, stb.
Egyebkent az en egyik winyomon (Maxtor 6E040L0) 75 reallocated sector van, es lassan no. Kb. 8 honap alatt 40 uj lett.
low level formatot legegyszerűbben úgy tudsz csinálni, hogy letöltesz 1 ubcd iso-t és felbootolsz róla. Van rajta egy csomó hdd utility, maxtor, wd, stb. és azok tudnak low level formatot. asszem ubcd.sourceforge.net, de google megmondja :)
Körbenéztem a témák között, de ilyet spec. nem találtam, ezért indítottam a topikot.
Van egy 8,4-es régebbi, ritkán használt quantum vinyóm, amin még tavaly felfedeztem 1 bad sectort (film másoláskor elakadt a művelet, és miután rezeteltem a gépet, zikszpé végignyomott rajta egy teljes felületellenörzést ami megtalálta a dögöt).
Azóta csak ritkán használtam, bekerült a tesztelö masinámba, amin nagy ritkán bsd-t nyúzok (ott nem nagy kár, ha adatvesztés lenne,és legalább könnyebben veszi rá magát az ember az újratelepítésre gyakorlás gyanánt). Pár alkalommal már bsd telepítő elhasalt másoláskor (gondolom épp a fentiek miatt) ezért bosszankodtam 1 kicsit h. miért nem ajánlja fel legalább 1 apró lehetöségként a teljes partíció/slice végigtekerését. Aztán levlistákon láttam, h. tul.képpen ez nem lenne a dolga, de attól még vhol be kellene iktatni ezt a műveletet! Ahogy láttam a linux képes readonly és destruktív tesztet is végignyomni a vinyón ha kérem.
Pár napja eszembe jutott az eset, és gondoltam akkor megpróbálom a hivatalos utat: maxtor gyár oldaláról lekaptam a powermaxot, dos rendszerlemezre rápakoltam, reboot és ráeresztettem a vinyóra. Karistolta jóideig, végül olyan szép PASSED-et kaptam mindenféle hibaüzenet nélkül, h. öröm volt nézni. Kipróbáltam mindenféle offline/online tesztet, de semmi. A smartot a SMARTMONTOOLS nevezetű (tényleg) fantasztikus programmal néztem meg. Ott is adtam neki mindent, amit csak támogatott a drájv, de még mindig semmi.
Ekkor jött az 5let: low level format. És így másfél óra írás után már meg is kérdezem: ez mit csinál igazából? Ahogy itt látom:
http://www.ariolic.com/activesmart/low-level-format.html
olyan h. low level format, a gyárból kijövet már nem lehet a meghajtón csinálni. Akkor ezek a programok low level format címén 1 sima wipeot művelnek, és ha ott tapasztalnak vmi gondot (visszaolvasáskor?) azt jelentik? Nekem legalábbis ez tűnt ki a működésükből. Ebben az esetben viszont bármely wipeolo megteszi, nem kell gyártóspecifikusnak lennie.
Nekem is volt már lemezen hasonló bad sector-om. Ez WD, 100 Gbyte-os. Náluk két tesztprogi van, persze mind a kettő ablakos, ill. az egyik van DOS alá is. A gyors program csak szúrópróba-szerűen ellenőriz, a másik végignyálazza az egész lemezt. Ez az utóbbi sikeresen rendbetette a diszkemet, már kb. egy éve, azóta hibátlanul működik. Később használtam egy nem WD gyártmányú 6 Gbyte-os diszkhez is, ott is jól szerepelt.
Azt persze nem tudom, hogy mit csinál :-( , de ha egy egyszerű 0-kkal teleírás nem segít, esetleg ezzel is érdemes próbálkozni.
a dd-s megoldás viszont emészthető. uazt csinálja mint anno a maxtor data erasere, tehát minden egységet felülír 0-val, értelemszerűen a töltőszektort is
Nem, a lowlevel formatterek nem csak siman wipeolnak. (az általad linkelt címen pedig keményen összekeverik, azért, mert windows alapból nem ad lehetőséget wipe-olásra és ezért a boot record törlése csak lowlevel formattal lehetséges. Kivéve, ha az embernek van egy linux live cd-je egy okos kis dd utility-vel :) )
Ehhez persze tudni kell, hogy a merevelemezeknek manapság igen komoly intim magánéletük van. :) Egyrészt ténylegesen nem azt írja rá a lemezre, amit az ide interfészen adatként kap és amit látsz, ha megnyitod mondjuk a /dev/hda-t, másrészt pedig egyáltalán az, hogy te a device fájlban egy folytonos lineáris címtartományt látsz egy igen bonyolult belső címfordítási folyamat eredménye.
Tehát először is a lemezek kapacitása ténylegesen kb 1,5-1,8 szorosa az általad kihasználható kapacitásnak. A tárolandó adatot ugyanis először egy egy elég nagy szóhosszúságú (200-300 bit körüli) Reed-solomon hibajavító kóddál látják el. (ami valójában persze nem reed-solomon, hanem un. BCH kód, mert a RS kódok csak prímrendű test felett értelmezettek, a biteknek a kétféle állapota ugyan prím, viszont ez a legalapabb triviális esete az RS kódoknak, ahol éppenhogy egyetlen hibát sem lehet javítani. A BCH ennek kiterjesztése több bites esetre, ennek ellenére mindenki reed-solomonnak csúfolja, ki tudja miért...)
Tehát a hibajavító kód alaból máris vagy ~40%-al (meg kéne nézni valami doksit, hogy pontosan mennyivel) felhízlalja az adatot. Viszont cserébe egy blokkon belül is elég sok bithibát képes javítani. Namost, ha fellép ilyen bithiba, akkor először is megismétli az olvasást, hátha csak átmeneti hiba volt, ilyenkor a Raw read error rate smart értéket növeli egyel, de semmi egyebet nem tesz. Ha viszont ismételten hibásnak olvassa, akkor a hibajavító kóddal kénytelen helyreállítani az adatot. Ezután megpróbálja visszaírni a javított változatot, valahova feljegyzi ezt is, talán a Hardware_ECC_Recovered smart értékbe. Ha a javítás ellenére is megint ott van a bithiba, akkor lemezfelületi hiba van. Ilyenkor el kell költöztetni az adatot a hibás blokkból. (a hibajavító kód most is lehetővé teszi, hogy adatvesztés nélkül vissza tudjuk nyerni az eredeti adatot) Az elköltöztetésnél jön be az, hogy a lemez felületének néhány százaléka fenn van tartva áthelyezett blokkok számára. Ilyenkor ide írja be az adatot, és feljegyzi a lemez elején egy speciális rendszerterületre (ami szintén rejtve van külvilág elől), a hibás blokknak a címét és hogy a lemezen fizikailag hova helyezte át. Ezután minden alkalommal, amikor a hányatott sorsú blokkunkhoz akar a rendszer hozzáférni, akkor azért a blokkért külön el kell menni oda, ahova át lett helyezve. Mindez el van rejtve a rendszer elől, legfeljebb a teljesítményből látszik, hogy tovább tart annak a blokknak az elérése, mert külön seekelni kell. No meg abból, hogy a smartban a relocated sector count 1-el megnőtt.
Namost a lemezfelületi hiba csak akkor derült ki, amikor ténylegesen hozzányúltunk a hibás részhez és a normális olvasás során a hibajavító kódból vette észre a winyó vezérlőprocesszora, hogy valami zűr van. (ugye akkor sem derül ki, ha a hibás felületelem úgy hibás, hogy mindig 0-bitet lehet onnan kiolvasni, és véletlenül tényleg 0-s bit kerül rá.)
A lowlevel format parancsa a vezérlőprocesszornak azt csinálja, hogy végigtesztel minden blokkot a lemez felületén, olyan helyeken is, ahova az operációs rendszer nem tud írni, mert a vinyó vezérlője elfedi, és úgy, hogy ténylegesen tesztmintákat ír a lemez felületére, ha valahol hiba van akkor azt reallokkálja. Ja meg ha jól tudom újraellenőrzi a hibásnak minősített területeket is és ha kiderül, hogy mégsem hibás (pl valami más hiba miatt gondolta korábban annak), akkor visszaminősíti jónak.
A sima wipe, vagy a badblocks program tesztmintái esetén nem a tesztminta kerül fizikailag a lemezre, hanem annak a hibajavító kóddal transzformált változata. Ezáltal rosszabb lehet a hibafedés. Arról nem is beszélve, hogy a speciális területeket sem teszteli le.
Namost idáig a világ szép és jó, minden rózsaszín, :) hiszen a csoda BCH kód mindig kijavítja a bithibát és így az oprendszer és a user nem is lát semmit az egészből. A baj akkor van, amikor egy blokkban túl sok bithiba van egyszerre (mert azok jellemzően nem egyesével szoktak jelentkezni, hanem burstökben) és már nincs elég redundancia a kódszavakban ahhoz, hogy az eredeti adatot vissza lehessen nyerni. Na ilyenkor van az, hogy a winyó egy kedves read_failure-el tér vissza. Akkor bizony a blokk tartalmát többet vissza nem hozza senki (esetleg a sok újrapróbálkozási kisérletben lehet, hogy véletlen sikerűl kijavítani, de ez ritka). Mivel ilyenkor automatikusan nem tud javítani a vinyó, ezért alapból nem is mappeli át a hibás blokkot, mert nem tudja garantálni, hogy a tartalma jó lesz. Tehát mindig hibát fog jelezni azon a helyen. Raid miatt fontos ez, mert az alapból feltételezi, hogy a vinyók vagy jó adatot adnak vissza, vagy hibát jeleznek, és ilyenkor innen tudja a raid vezérlő, hogy akkor azt az adatot pótolni kell egy másik lemezről. Nagyon megtévesztő lenne, ha a sikertelen átmentés után mégis átmappelné a hibás címet más helyre, így minden hibajelzés nélkül csak úgy megváltozna az adat egy blokkban.
A low level formatnál viszont úgyis törlődik minden adat, tehát ilyenkor megcsinálja azokat az áthelyezéseket is, amiket idáig a hibajelzés fenntartása miatt nem lehetett. Tehát a lowlevel látszólag kijavítja a javíthatatlan hibákat is. Azonban ha már volt javíthatatlan hiba, akkor gyanús, hogy a merevlemeznek valami mechanikai baja is van (pl meglazult a fej konzol és a fej időnkét hozzáütődik a lemezfelülethez), és ezért lehet számítani hogy lesz több is.
Hozzászólások
Van e arra lehetoseg hogy kinyerjunk a vinyobol adatot arra nezve, volt e valamilyen irasi-olvasasi hiba. Ami soha nem jutott felhasznaloi szintre. Igy esetleg fel lehet keszulni adatvesztesre, megelozesre. :roll:
Laptop-ot hasznalok igy ott kiemelten elofordulhat ilyen.
Valaki azt tanacsolta hogy vegleges adatvesztes eseten erdemes megprobalni a vinyot lehuteni es egy probat tenni.
:lol:
[quote:e2c71ea189="monas"]Van e arra lehetoseg hogy kinyerjunk a vinyobol adatot arra nezve, volt e valamilyen irasi-olvasasi hiba. Ami soha nem jutott felhasznaloi szintre. Igy esetleg fel lehet keszulni adatvesztesre, megelozesre. :roll:
Ha smart jól van megcsinálva a konkrét vinyóban, akkor az pont arra való. A raw value-kat kell nézni:
1 Raw_Read_Error_Rate
5 Reallocated_Sector_Ct
195 Hardware_ECC_Recovered
az 1-es és 195-ösből, normális üzem közben mondjuk 1 év használat alatt 1-2000 darab normális. (Kivéve a seagate-eknél, mert ott rejtélyes módon több tíz milliót jeleznek a teljesen hibátlanul működö darabok is. Több 10 darab fordult már meg nálam a 7200.X-es szériákból, az összes ilyen volt, annak ellenére, hogy vadonat újak voltak. Vagy típushiba, vagy pedig a seagate valami teljesen más értelmezést adott a számoknak.)
Az 5-ösől több év használat során lehet 1-2 darab. Ha ezek szaporodnak, akkor kell nagyon sürgősen biztonsági másolatot csinálni. A smartd-t be lehet állítani, hogy riasszon, ha ez emelkedik. Alapból mindenre riaszt, vicces dolog látni a logokban, a temperature_celsius changed from 41 to 42 bejegyzéseket. :)
Hát az attól függ mi a hiba. Van amikor segít, van amikor kifejezetten ez teszi tönkre, és sajnos nincs rá általános szabály, hogy mikor melyik. A páralecsapódás nagy ellensége a vinyóknak, márpedig a lehűtésnél ez könnyen előfordul. A lemez és a fej között annyira kicsi a rés, hogy a páraréteg sokkal vastagabb annál. Egyszer kipróbáltam egy régi rossz mfm vinyóval (pedig ott még a maiaknál sokkal nagyobb légrés volt). Alapból simán forgott a lemez benne, mikor finoman ráleheltem azonnal megszorult és keményen befékeződött! Mihelyt elpárolgott a lemez azonnal újraindult, de utána látni lehetett egy finom karcolást ott ahol fej megszorult. Elég durva...
A gyártóknak egyébként is van egy elég szigorú előírása a maximális hőváltozási sebességre, azt hiszem olyan 5 C/10perc vagy valami hasonló üzem közben, és 10 C/10perc kikapcsolt állapotban. Namost ha hidegen indítják el, akkor könnyen lehet, hogy saját maga gyorsabban melegszik fel. Ez általában nem szokott baj lenni, kivéve a régebbi sokat szidott quantum lct szériát, na azokat nagyon könnyen meg lehet ezzel ölni.
Nekem adatmentésnél pont az szokott segíteni, ha üresen járatom és hagyom felmelegedni normális üzemi hőmérsékletre és csak ezután próbálok meg olvasni róla. Ettől még lehet, hogy tényleg segít a lehűtés is bizonyos esetekben, elég sok helyről hallottam már ilyet, csak óvatosan kell csinálni.
[quote:aba56e26ae="XMI"]
Ha smart jól van megcsinálva a konkrét vinyóban, akkor az pont arra való. A raw value-kat kell nézni:
1 Raw_Read_Error_Rate
5 Reallocated_Sector_Ct
195 Hardware_ECC_Recovered
az 1-es és 195-ösből, normális üzem közben mondjuk 1 év használat alatt 1-2000 darab normális.
Van ket ibm vinyom raid-ben par eve az itthoni gepben. Kicsit furak lettek az eredmenyek
Az egyiknel van raw_read_error_rate, 65536, ami ugye 2 hatvanya pont.., es nulla reallocated, a masiknal 0 a raw_read_error, es van hozza 6 athelyezett.
A kb 4-5 eves ibm-re mindketto 0.
A laptopban kb 1 eves ibm szinten 0/0
Ezek lehetnek realis ertekek?
XMI: köszi a kimerítő :) válaszokat, ezt akár wiki-be is átkoppizhatnád!
XMI ez jó volt... thx.
egyébként nállam egy Maxtor 4R080L0-asnál nincs
Raw_Read_Error_Rate, a Reallocated_Sector_Ct az zérus, és a
Hardware_ECC_Recovered meg 26788. a winyó 121 órát futott
most akkor mi van?
egyébként a másik Maxtor 6E040L0-esemnél sincs 1-es, az 5-ös 0, a
195-ös meg 1185. ez már 190 óránál tart.
miért nincs Raw_Read_Error_Rate az egyiknél sem?
egyébként satás winyókra van valami hasonló trükk mint a smart az atákra?
köszi.
Az en vinyom ezt kopi ki, zt3000 HP noteboot, 9 honapos, segitsetek ezt ertelmezni:
Location IDE eszköz A
Drive size 56 GB
Make and model FUJITSU MHT2060AT PL
Supports SMART? Igen
SMART enabled? Igen
Errors logged 1 errors detected
Passed drive check? Igen
Offline data collection status Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline data collection 440 seconds.
Offline data collection capabilities SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability Error logging supported.
No General Purpose Logging support.
Short self-test routine recommended polling time 2 minutes.
Extended self-test routine recommended polling time 60 minutes.
Conveyance self-test routine recommended polling time 2 minutes.
Raw Read Error Rate 64689
Throughput Performance 21758291
Spin Up Time 0
Start Stop Count 2537
Reallocated Sector Ct 8589934592000
Seek Error Rate 3337
Seek Time Performance 0
Power On Hours 11565549
Spin Retry Count 0
Power Cycle Count 972
Power-Off Retract Count 60
Load Cycle Count 27044
Temperature Celsius 43
Hardware ECC Recovered 136
Reallocated Event Count 285736960
Current Pending Sector 0
Offline Uncorrectable 0
Multi Zone Error Rate 11075
Run Out Cancel 2628549935473
[quote:9ca620d50a="ricsip"]XMI: köszi a kimerítő :) válaszokat, ezt akár wiki-be is átkoppizhatnád!
Jaj, ahhoz előbb helyesírásilag, meg megfogalmazásilag rendbe kellene raknom, és most nagyon nincs kedvem hozzá. Meg a másik az, hogy ami értékeket én körülbelül saccra beírtam, azoknak ténylegesn utána kellene nézni a gyártó doksijában (rég olvastam már nagyon), mert a wiki-t azért komoly referenciaként is használják sokan.
Majd esetleg egy kicsit később, vagy ha valaki érez rá ihletet most, akkor szívesen átadom a jogot neki.
Ami pedig a konkrét kérdéseket illeti:
Sajnos nem vagyok se orákulum, se pedig Kürti Sándor, hogy ismerjem a gyárók egyéni hülyeségeit. A közelmúltban maxtort és seagate-et láttam viszonylag sokat, ezekről tudok úgy-ahogy nyilatkozni.
Maxtoréknál tényleg nincs Raw_read_error rate, ezt én is észrevettem. Ezen kívül náluk az üzemóra számláló 49 nap (2^32sec, ~1193 óra) után körbefordul! (Igen, így aztán az égegyadta világon semmi értelme nincsen.)
A 8589934592000 pedig 2^33*1000. Ennyi blokk biztos nincs a lemezen összesen, lehet, hogy a -1-et ábrázolják így. Azt, hogy mi a jelentése csak a gyártó tudná megmondani, ha akarná. Ja igen a smartmontools egyébként rengeteg gyártó-specifikus kódot tartalmaz, tehát ha hülyeségnek látszó értéket ad vissza, akkor meg kell próbálni újabb verziót, hátha ott már támogatva van a konkrét típus.
Az egész smartnak egyébként pont ez a halála. Minden gyártó egy saját maga által választott részhalmazát implementálja és egyéni értelmezést ad a számoknak. A rendes érték (tehát nem raw), ennek a kiküszöbölésére van, de itt is vannak eltérések. A maxtornál pl alapból 255-ről (némelyik meg 200-ról) indul , a seagate-nél jellegzetesen 100-ról. Elvileg akkor van gáz, ha az érték a treshold alá megy. Csakhogy én több olyan haldokló vinyót is láttam, ahol még súlyos adatvesztés után sem ment le az érték a treshold alá (pedig a raw value-kból látszott, hogy baj van). Ezért kell jobb híján a raw értékeket nézni, feltéve, hogy értelmes adatot ad vissza.
Talán az lehet az oka, hogy nem akarnak false positive riasztást, mert akkor sok felesleges garanciális csere lenne. Az más kérdés, hogy egy false negative viszont adatvesztéssel jár, és a felhasználó szemszögéből ez nagyobb gáz.
[quote:fdb790ab9f="XMI"]Az 5-ösől több év használat során lehet 1-2 darab.
Öhm. Most néztem meg (maxtor 4d040h2) és 63-at mutat. Ez akkor most azt jelenti, hogy ideje lesz bevásárolni. Még szerencse, hogy nekiálltam itt olvasgatni az éjszaka közepén. :D
Reallocated Sector Ct 8589934592000
Hogy ez a 2 hatvanya mindent elmond, azaz semmit.
Kossz szepen! :lol:
Uhh...
[code:1:5ef7988be7]
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0
5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0
195 Hardware_ECC_Recovered 0x000a 100 100 000 Old_age Always - 64282237
[/code:1:5ef7988be7]
Itt most a Raw értéket kell nézni, ugye? (5ösből 253 "kicsit" sok egy látszólag teljesen jól működő winyónak o_O)
[quote:632fa35ecf="Csigaa"]Uhh...
[code:1:632fa35ecf]
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0
5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0
195 Hardware_ECC_Recovered 0x000a 100 100 000 Old_age Always - 64282237
[/code:1:632fa35ecf]
Itt most a Raw értéket kell nézni, ugye? (5ösből 253 "kicsit" sok egy látszólag teljesen jól működő winyónak o_O)
A sor vegen 0 van az 5-os raw_value-nal, ha jobban megnezed.
XMI: kopizd be wiki-be, akkor az szerkesztheti/pofozhatja, aki szeretné és ért hozzá :)
Linux alatt hogyan tudok low level formatot végezni?
ennél mélyebbre ne menj:
dd if=/dev/zero of=/dev/hdx
Hi!
Nemely, foleg regebbi BIOS tud lowlevel formatot. Viszont ezt _tilos_ haznalni, mert tobbet artasz vele, mint hasznalsz. En olyat olvastam, hogy ugyebar a cylinderek nem egyforma hosszuak, igy ami kozelebb van a lemez szelehez, oda tobb adatot lehet tenni. Erre eleg bonyolult algoritmus van, amit a gyarto nem mond meg. Viszont a BIOS-os lowlevel formatnal ha minden igaz, minden cylinderen ugyanannyi adat lesz, igy csokken a winyo kapacitasa, es allitolag mas tekintetben is rossz. Max akkor erdemes vele kiserletezni, ha a winyo abszolut nem mukodik, vagy a fele badsector, stb.
Egyebkent az en egyik winyomon (Maxtor 6E040L0) 75 reallocated sector van, es lassan no. Kb. 8 honap alatt 40 uj lett.
By(t)e
TBS::Antiemes
low level formatot legegyszerűbben úgy tudsz csinálni, hogy letöltesz 1 ubcd iso-t és felbootolsz róla. Van rajta egy csomó hdd utility, maxtor, wd, stb. és azok tudnak low level formatot. asszem ubcd.sourceforge.net, de google megmondja :)
Helló mindenkinek!
Körbenéztem a témák között, de ilyet spec. nem találtam, ezért indítottam a topikot.
Van egy 8,4-es régebbi, ritkán használt quantum vinyóm, amin még tavaly felfedeztem 1 bad sectort (film másoláskor elakadt a művelet, és miután rezeteltem a gépet, zikszpé végignyomott rajta egy teljes felületellenörzést ami megtalálta a dögöt).
Azóta csak ritkán használtam, bekerült a tesztelö masinámba, amin nagy ritkán bsd-t nyúzok (ott nem nagy kár, ha adatvesztés lenne,és legalább könnyebben veszi rá magát az ember az újratelepítésre gyakorlás gyanánt). Pár alkalommal már bsd telepítő elhasalt másoláskor (gondolom épp a fentiek miatt) ezért bosszankodtam 1 kicsit h. miért nem ajánlja fel legalább 1 apró lehetöségként a teljes partíció/slice végigtekerését. Aztán levlistákon láttam, h. tul.képpen ez nem lenne a dolga, de attól még vhol be kellene iktatni ezt a műveletet! Ahogy láttam a linux képes readonly és destruktív tesztet is végignyomni a vinyón ha kérem.
Pár napja eszembe jutott az eset, és gondoltam akkor megpróbálom a hivatalos utat: maxtor gyár oldaláról lekaptam a powermaxot, dos rendszerlemezre rápakoltam, reboot és ráeresztettem a vinyóra. Karistolta jóideig, végül olyan szép PASSED-et kaptam mindenféle hibaüzenet nélkül, h. öröm volt nézni. Kipróbáltam mindenféle offline/online tesztet, de semmi. A smartot a SMARTMONTOOLS nevezetű (tényleg) fantasztikus programmal néztem meg. Ott is adtam neki mindent, amit csak támogatott a drájv, de még mindig semmi.
Ekkor jött az 5let: low level format. És így másfél óra írás után már meg is kérdezem: ez mit csinál igazából? Ahogy itt látom:
http://www.ariolic.com/activesmart/low-level-format.html
olyan h. low level format, a gyárból kijövet már nem lehet a meghajtón csinálni. Akkor ezek a programok low level format címén 1 sima wipeot művelnek, és ha ott tapasztalnak vmi gondot (visszaolvasáskor?) azt jelentik? Nekem legalábbis ez tűnt ki a működésükből. Ebben az esetben viszont bármely wipeolo megteszi, nem kell gyártóspecifikusnak lennie.
Köszi, akkor meggondolom, hogy használjam-e!
Nekem is volt már lemezen hasonló bad sector-om. Ez WD, 100 Gbyte-os. Náluk két tesztprogi van, persze mind a kettő ablakos, ill. az egyik van DOS alá is. A gyors program csak szúrópróba-szerűen ellenőriz, a másik végignyálazza az egész lemezt. Ez az utóbbi sikeresen rendbetette a diszkemet, már kb. egy éve, azóta hibátlanul működik. Később használtam egy nem WD gyártmányú 6 Gbyte-os diszkhez is, ott is jól szerepelt.
Azt persze nem tudom, hogy mit csinál :-( , de ha egy egyszerű 0-kkal teleírás nem segít, esetleg ezzel is érdemes próbálkozni.
Üdv,
L. Á.
a dd-s megoldás viszont emészthető. uazt csinálja mint anno a maxtor data erasere, tehát minden egységet felülír 0-val, értelemszerűen a töltőszektort is
Nem, a lowlevel formatterek nem csak siman wipeolnak. (az általad linkelt címen pedig keményen összekeverik, azért, mert windows alapból nem ad lehetőséget wipe-olásra és ezért a boot record törlése csak lowlevel formattal lehetséges. Kivéve, ha az embernek van egy linux live cd-je egy okos kis dd utility-vel :) )
Ehhez persze tudni kell, hogy a merevelemezeknek manapság igen komoly intim magánéletük van. :) Egyrészt ténylegesen nem azt írja rá a lemezre, amit az ide interfészen adatként kap és amit látsz, ha megnyitod mondjuk a /dev/hda-t, másrészt pedig egyáltalán az, hogy te a device fájlban egy folytonos lineáris címtartományt látsz egy igen bonyolult belső címfordítási folyamat eredménye.
Tehát először is a lemezek kapacitása ténylegesen kb 1,5-1,8 szorosa az általad kihasználható kapacitásnak. A tárolandó adatot ugyanis először egy egy elég nagy szóhosszúságú (200-300 bit körüli) Reed-solomon hibajavító kóddál látják el. (ami valójában persze nem reed-solomon, hanem un. BCH kód, mert a RS kódok csak prímrendű test felett értelmezettek, a biteknek a kétféle állapota ugyan prím, viszont ez a legalapabb triviális esete az RS kódoknak, ahol éppenhogy egyetlen hibát sem lehet javítani. A BCH ennek kiterjesztése több bites esetre, ennek ellenére mindenki reed-solomonnak csúfolja, ki tudja miért...)
Tehát a hibajavító kód alaból máris vagy ~40%-al (meg kéne nézni valami doksit, hogy pontosan mennyivel) felhízlalja az adatot. Viszont cserébe egy blokkon belül is elég sok bithibát képes javítani. Namost, ha fellép ilyen bithiba, akkor először is megismétli az olvasást, hátha csak átmeneti hiba volt, ilyenkor a Raw read error rate smart értéket növeli egyel, de semmi egyebet nem tesz. Ha viszont ismételten hibásnak olvassa, akkor a hibajavító kóddal kénytelen helyreállítani az adatot. Ezután megpróbálja visszaírni a javított változatot, valahova feljegyzi ezt is, talán a Hardware_ECC_Recovered smart értékbe. Ha a javítás ellenére is megint ott van a bithiba, akkor lemezfelületi hiba van. Ilyenkor el kell költöztetni az adatot a hibás blokkból. (a hibajavító kód most is lehetővé teszi, hogy adatvesztés nélkül vissza tudjuk nyerni az eredeti adatot) Az elköltöztetésnél jön be az, hogy a lemez felületének néhány százaléka fenn van tartva áthelyezett blokkok számára. Ilyenkor ide írja be az adatot, és feljegyzi a lemez elején egy speciális rendszerterületre (ami szintén rejtve van külvilág elől), a hibás blokknak a címét és hogy a lemezen fizikailag hova helyezte át. Ezután minden alkalommal, amikor a hányatott sorsú blokkunkhoz akar a rendszer hozzáférni, akkor azért a blokkért külön el kell menni oda, ahova át lett helyezve. Mindez el van rejtve a rendszer elől, legfeljebb a teljesítményből látszik, hogy tovább tart annak a blokknak az elérése, mert külön seekelni kell. No meg abból, hogy a smartban a relocated sector count 1-el megnőtt.
Namost a lemezfelületi hiba csak akkor derült ki, amikor ténylegesen hozzányúltunk a hibás részhez és a normális olvasás során a hibajavító kódból vette észre a winyó vezérlőprocesszora, hogy valami zűr van. (ugye akkor sem derül ki, ha a hibás felületelem úgy hibás, hogy mindig 0-bitet lehet onnan kiolvasni, és véletlenül tényleg 0-s bit kerül rá.)
A lowlevel format parancsa a vezérlőprocesszornak azt csinálja, hogy végigtesztel minden blokkot a lemez felületén, olyan helyeken is, ahova az operációs rendszer nem tud írni, mert a vinyó vezérlője elfedi, és úgy, hogy ténylegesen tesztmintákat ír a lemez felületére, ha valahol hiba van akkor azt reallokkálja. Ja meg ha jól tudom újraellenőrzi a hibásnak minősített területeket is és ha kiderül, hogy mégsem hibás (pl valami más hiba miatt gondolta korábban annak), akkor visszaminősíti jónak.
A sima wipe, vagy a badblocks program tesztmintái esetén nem a tesztminta kerül fizikailag a lemezre, hanem annak a hibajavító kóddal transzformált változata. Ezáltal rosszabb lehet a hibafedés. Arról nem is beszélve, hogy a speciális területeket sem teszteli le.
Namost idáig a világ szép és jó, minden rózsaszín, :) hiszen a csoda BCH kód mindig kijavítja a bithibát és így az oprendszer és a user nem is lát semmit az egészből. A baj akkor van, amikor egy blokkban túl sok bithiba van egyszerre (mert azok jellemzően nem egyesével szoktak jelentkezni, hanem burstökben) és már nincs elég redundancia a kódszavakban ahhoz, hogy az eredeti adatot vissza lehessen nyerni. Na ilyenkor van az, hogy a winyó egy kedves read_failure-el tér vissza. Akkor bizony a blokk tartalmát többet vissza nem hozza senki (esetleg a sok újrapróbálkozási kisérletben lehet, hogy véletlen sikerűl kijavítani, de ez ritka). Mivel ilyenkor automatikusan nem tud javítani a vinyó, ezért alapból nem is mappeli át a hibás blokkot, mert nem tudja garantálni, hogy a tartalma jó lesz. Tehát mindig hibát fog jelezni azon a helyen. Raid miatt fontos ez, mert az alapból feltételezi, hogy a vinyók vagy jó adatot adnak vissza, vagy hibát jeleznek, és ilyenkor innen tudja a raid vezérlő, hogy akkor azt az adatot pótolni kell egy másik lemezről. Nagyon megtévesztő lenne, ha a sikertelen átmentés után mégis átmappelné a hibás címet más helyre, így minden hibajelzés nélkül csak úgy megváltozna az adat egy blokkban.
A low level formatnál viszont úgyis törlődik minden adat, tehát ilyenkor megcsinálja azokat az áthelyezéseket is, amiket idáig a hibajelzés fenntartása miatt nem lehetett. Tehát a lowlevel látszólag kijavítja a javíthatatlan hibákat is. Azonban ha már volt javíthatatlan hiba, akkor gyanús, hogy a merevlemeznek valami mechanikai baja is van (pl meglazult a fej konzol és a fej időnkét hozzáütődik a lemezfelülethez), és ezért lehet számítani hogy lesz több is.