Caponi rašė:
> I Pending Sectors atributa su 20 reiksme nemaza dalis (bet ne visi)
> SMART interpretatoriu nekreips demesio, t.y. bendras disko bukles
> ivertinimas bus "Good" arba "OK"
Man rodos, kad *dauguma* nors kiek rimtesnių perspės, net jei čia bus
vos 1 sektorius.
> Bet kokiu atveju snekant apie si konkretu atveji as jau parasiau - BAD'u
> realiai tikriausiai tukstanciai (pilno testo nedariau, prasmes nebuvo
> pamacius kas darosi jau pacioj testo pradzioj), o ne 20 ar 30, laiko
> SMART'ui susitvarkyt savo reiksmes buvo irgi dafiga, tame tarpe ir
> pradet bent viena kita sektoriuka remapint.
Tai iš kur bad sektoriai? Ir dar tūkstančiai jų? Iš kur? Nėra dar bad
sektorių, jei neturi realllocate'into nė vieno. Tuo labiau, kad tik 20
kandidatų į remap'ą, o ne tūkstančiai.
> Berods UNC, nors siuo atveju galvos nukirst neduociau, kai pamaciau
> kokiais tempais sarasiukas dideja, daugiau klausimu neliko. Jei cia
Kabelis dažnai būna kaltas, kiek susidariau nuomonę iš mhdd forumų. Tai
dar ne fiziniai bad'ai. Kol nėra reallocated sektorių, tol tu dar neturi
nė vieno tikro bad'o (išskyrus IDNF ir AMNF).
> keli-keliolika realocated sektoriu nera joks vienareiksmiskas ir
> neabejotinas disko sveikatos rodiklis apart Googles apimciu statistikos,
Jau gana vienareikšmiškas.
> Nieko as nemaisau.
> UNC siaip jau sifruojasi kaip "data is uncorrectable" ir nieko nesako
> apie softine ar hardwarine to sektoriaus blogumo prigimti. Jei LLF
> padeda, reiskias problema buvo softine, jei ne - tikras BAD'as.
Jo, tik UNC praktiškai reiškia neteisingą CRC ir nereikia jokio LLF, kad
tą sektorių tiesiog banaliai perrašyti (perrašant failą/duomenis OS'e)
ir tokiu būdu atnaujinti/pataisyti sektoriaus CRC. Jei tai nepavyksta,
tai sektorius — į karantiną (pending) ir/ar remap. Ir atitinkamai
užsikelia smart'o counter'iai. Taigi, jei teturi 20 pending sektorių
smart'e (ir dar nė vieno remap'o), tai reiškia, kad tik ant dvidešimties
nestabilių sektorių užsirovei, o visi kiti (tavo numanomi tūkstančiai) į
juos pataikant rašyti OS'ui yra sėkmingai įrašomi su korektišku CRC ir
tai (tūkstančiai UNC prie keliasdešimties pending) veikiausiai yra
soft'inė bėda.
Todėl, pasikartosiu, kol neturi reallocate'into, tol neturi bad'o.
> Esme tame, kad grazioj teorijoj turetu atsirandanciais fiziniais BAD'ais
> uzsipildyt realokeitintu sektoriu limitas (zinoma, su salyga, kad HDD ne
> i siena veikiantis buvo paleistas :-)), kurie "isimami" is realaus disko
> "zemelapio" ir niekam is isores nera matomi atliekant iprasta pavirsiaus
> skenavima, ir tik jam issekus atsirast blogi sektoriai, identifikuojami
> kad ir windowsinio checkdisko ir nusinesantys naxren informacija.
> Praktikoj as tau realu pavyzdi duodu, kai SMART'as laiko susitvarkyt
> turejo kaip minimum kelias-keliolika savaiciu (sprendziant is juzerio
Būtent taip ir vyksta praktikoje. Tik tu, panašu, atsisakai tai suvokti
:-) Jei rašant į tokius sektorius jie vis neremap'inami, tai gali būti
tikras, kad jie ir nėra blogi, nes hdd as su jais tvarkosi paprastai:
bandymas įrašyti, perskaitymas ir sprendimas (priklausomai nuo to ar
pavyko) — remap ar sveikas.
Būtent todėl akcentuoju soft'ines problemas (ypač dar tūkstančiais UNC),
nes dėl jų fs'as pabyra, o reallocated neatsiranda.
> gerokai anksciau susirupint xulish jo kompas gliuchina), o praktiskai
> gal ir indikuoja apie galima problema su tais savo ~20 ITARTINU
> sektoriu, bet nikuja nepsako apie tai, kad tas diskas siuo momentu yra
> LAVONAS, kuriam jau gerokai per velu kazka realokeitint.
Pasikartosiu, ko, panašu, neišgirdai. Problemas veikiausiai būtum
aptikęs skenuodamas diską vos po pirmo pending sektoriaus pasirodymo ar
paleidęs smart'o offline scan'ą. Tuo labiau smart'o offline scan'ą, nes
jis aptinka bad sektorius (jei tokių būtų), kurie būtų remap'inti.
O tu teigi, kad smartas neveikia. :-)
Veikia ir šis atvejis neišimtis, nes smartas user'į įspėjo (ką smart'ui
reikėjo daryti, kad user'is nesiteikė smart'o paklausti? gal caps lock'u
SOS pamirkėti?) gerokai anksčiau, nei jam pabyrėjo fs'as. Atmetus žinoma
atvejus, kai pavyzdžiui galva staigiai pradėjo drožti diską ir visi tie
20 pending sektorių (su tūkstančiais UNC) susikrovė per sekundę-dieną.
> Va dar konkretus gana neseniai egzempliorius mano rankose pabuvojes -
> SMART'as svarus, esminese pozicijose nuliukai. Victoria mazdaug puses GB
> intervale parode kruvele letu ir keleta nenuskaitomu sektoriu. LLF
> padarytas, keli is eiles pavirsiaus skenavimai rodo panasias
> tendencijas, bet kiekviena karta leti ir/ar nenuskaitomi sektoriai (t.y.
> ju kartais ir nerodoma, kaip zinia, sektorius kaip nenuskaitomas
> identifikuojamas, kai jis per nustatyta laika "neatsako") yra vis kitose
> vietose ("teritorija" ta pati), ju bendras kiekis skiriasi, windowsinis
> checkdiskas irgi randa nuo 0 iki 5-6 BAD'u priklausomai "nuo nuotaikos".
> Isvada - akivaizdziai problemine zona, kaip minimum reiskianti toje
> vietoje infos nuskaitymo suletejima, o realiai - didele rizika prarast
> duomenis, diska naudot galima ta zona "iskerpant" sukuriant atitinkamose
> vietose particijas ir stebint situacija (arba tiesiog laikyt labai
> laikinu duomenu n-taja kopija :-)). SMART, savaime aisku, apie tai nei
> kriukt, trumpasis gamintojo testo variantas irgi tyli, nes ten kaip
> taisykle yra tik SMART analize ir isvados pagal gamintojo algoritma.
> Isvada - SMART kaip problemu prevencija nesuveike...
Vėlgi, panašu į bullshit'ą arba kažką vėl nutylėjai; kaip ir pirmuoju
atveju smart'as, pasirodo, nieko nerodė, nors rodė 20 pending (t.y.
*neperskaitomų*) sektorių... :-)
Jei neatsiranda reallocated sektorių, tai bad'ų ir nėra. Interface'o
klaidos dar ir atskirą atributą turi.
Vienintelė galimybė (be kontrolerio gliukų ir kabelio problemų)
pabyrėti fs'ui (chkdsk rasti bad'ų), tai užsirauti ant nestabilaus ir
*neperskaitomo* sektoriaus, kuris esu beveik garantuotas (esu skaitęs
atsiliepimus mhdd guru forumuose, kad smart'as arba retais atvejais
neveikia iš viso arba veikia patikimai absoliučioje daugumoje atvejų)
gultųsi į pending ir tokiu būdu tau iš anksto indikuotų apie išsamesnės
diagnostikos būtinybę. Taigi, pyk nepyk, bet abejoju tavo teiginiu, kad
smart'as buvo švarus. Tuo labiau, kad jau padarei tokią klaidą dėl
smart'o švarumo.
>
>>> gult, kad ju softukas minutes tikslumu parodo hardui likusi gyvenimo
Niekur nesu minėjęs, kad remiuosi kažkokiomis hdd likusio gyvenimo laiko
prognozėmis, išskyrus tikimybinę statistiką.
> darosi negero", bet tik tiek ir be jokiu garantiju, kad ta signala gausi
> laiku. Bet vien pagal SMART nedarau absoliuciai jokiu isvadu ir labai
Kodėl man atrodo, kad „laiku“ reiškia „prieš laiką“? :-)
Signalą laiku (ir net anksčiau, prieš stipriau pabyrant fs, prarandant
duomenis) tikrai nemenkos galimybės ir tikimybė gauti. Būna, žinoma
atvejų, kad diskas užsilenkia visiškai staiga, akimirksniu (nulekia
kontroleriai, sugenda galvos), tačiau jie tikrai nėra vyraujantys ir juk
tuo labiau nepagrįsta tikėtis, kad smart'as apie juos perspės...
> gali but, kad ne visada i ji net ziureciau, jei jo "istraukimas" truktu,
> pvz., tiek pat, kiek gerokai informatyvesnis pavirsiaus scanas. Kaip
Trūkt ir vėl iš pradžių. Jei scan'ą tu darai be smart'o, tai apskritai
kvailai darai. Signalas scan'ui (be rutininio) visų pirma yra smart'as,
o ne atvirkščiai: pirma padarysiu scan'ą ir radęs klaidų nusistebėsiu,
kaip čia ir smart'as manęs neperspėjo, nors jo ir neklausiau...
> (ar "nespejo") sutrimituot apie uzgriusiancia beda. Kad yra tokiu
O kas suspėtų geriau už smart'ą? Nereikia jo demonizuoti, nes jis
tiesiog praneša apie būklę aibe reikšmingų parametrų. Reikšmingesnių
tiesiog nėra. Ir jei šie parametrai nieko nepasako apie užgriūsiančią
bėdą, tai tuo labiau nepasakys ir mhdd scan'as (na, sulėtėjo, atsirado
vietomis žaliukų, o kada jie pavirs bad'ais, jei išvis pavirs, tai
visiškai neaišku). Kritiniai parametrai praneša apie jau
esančias/kylančias problemas ir juos nuskaityti/sekti yra žymiai
greičiau ir paprasčiau, nei skenuoti visą diską mhdd. Pasikartosiu,
tikrai netikiu, kad įmanoma dėl hdd (atmetus kabelio problemas)
įsitaisyti bad'ą fs'e neapturėjus pending sektoriaus SMART'e.