[BSD] adatvesztes megelozese?

Adam Szilveszter adam at hif.hu
2003. Dec. 2., K, 08:31:55 CET


Szia!

Ha esetleg mar nagyon unnal, akkor elnezest kerek, segiteni probalok...

Marton Fabo wrote:

> Rendben. A jo backup megoldas (az en esetemben) nem alternativa. Ugyanis 
> a konkret rendszer, amivel kapcsolatban erdekelne az eredetileg 
> felvetett funkcio, egy szoba sakaba beallitott, nehany winchesterrel 
> megtomott kis BSD-s gep, epp a halozati mentesre, a win/Mac asztali 
> gepek moge. Ergo, a backupon mar tul vagyunk.

Vilagos es nagyon derek.

> CD-re, szalagra nem vagyok 
> hajlando menteni (legalabbis mindent nem; sok, lassu, macera), de azert 
> nem jonne jol, ha a kiscsalad altal netrol lecibalt mindenfele, meg a ki 
> nem irt munkak buknanak.

DVD iro? De most komolyan, mar egesz olcsok es egesz gyorsak. Es a 
FreeBSD szepen tamogatja oket, mikor eppen nincs rossz napja az 5.x-ben. 
En is gondolkodtam egyen, csak az a baj, hogy az en gepem laptop es 
ezert csak kulso megoldas johetne szamitasba, amit viszont a legujabb 
jelentesek szerint nem eppen A-OK minosegben tamogat a rendszer. Kar, 
mert eppen ez egy olyan hely, ahol nagyon nem szeretem a rejtelyes hibakat.

> Igy a cel az lenne, hogy a backupnak szant vinyokra valaki/valami 
> figyelne kisse, es egy paraszthajszalnyival tobb eselyem legyen ra, hogy 
> mielott a kovetkezo 120 giga fustbe megy, uj darabra tudjam atmenteni.

Vilagos.

> Miutan a felvetett hasonlat a pofatlan szemfenyvesztes alapos gyanujaval 
> csunyan megbukott,

Csak meg egy megjegyzes, inkabb kiegeszites jelleggel, ami mar a HEV-en 
jutott eszembe hazafele menet: Ha a grc-s programnak ismernie kell a 
fajlrendszer tipusat, akkor az mar eleve nem valami jo, mert akkor 
valojaban nem a lemezt teszteli, hanem a fajlrendszert, ami egy joval 
magasabb szint. (BSD-n pl VFS) Ezert az o tesztejeibe a lemez-cache-tol 
kezdve sok minden bezavarhat. Ha valoban a lemezt akarna figyelni, akkor 
az egyes szektorokat kellene kozvetlenul, a fajlrendszertol fuggetlenul 
gyakorlatoztatnia, ugyelve ra, hogy ne a cache-bol kapjon valaszt.

Sajnos erre a potencialis hibaforrasra (a cache az adatot elfogadta es 
ugy jelezte, hogy minden rendben, mikozben tenylegesen meg nem irta ki 
es ezert hirtelen rendszerleallasnal elveszett)tobben a sajat karukon 
voltak kenytelenek rajonni a FreeBSD-current listan mostanaban. Nem egy 
elmeny...

> toletek kerdezem, milyen eszkozok, modeszerek allnak 
> rendelkezesre, amivel probalkozhatom.

Mint mas helyen mar elhnagzott, ha a lemezed tamogatja a SMART 
monitoring szabvanyt (aminek a valoszinusege igen nagy) akkor 
hasznalhatod a FreeBSD portsbol a sysutils/smartmontools csomagot, ami 
szepen kiolvassa neked azokat az informaciokat amiket a lemez 
elektronikaja gyujt hibakrol, korrekciokrol stb. Ezt az outputot 
rendszeresen figyelve szerintem valamelyest keszulhetsz a cserere. Nem 
100%-os a dolog, de meg azelott fog jelezni, hogy a logokban az elso 
"hard error reading..." kezdetu hibak felbukkannanak.

> Valoban igaz (szerintetek), hogy a 
> GRC-n emlitett minden (elvi) modszer abszolut hatastalan, cserebe csak 
> gyorsitja az amortizaciot? 

En ott konkretan egy elvi modszert lattam, ha valaki mast is latott, 
akkor javitson ki. A program azt allitja magarol, hogy specialis 
mintakkal irogatja a lemezt es megnezi, hogy pontosan visszakapja-e. Ha 
nem, akkor megkiserli a hibas reszt elszigetelni. (Mar itt van valami 
budos nekem egyebkent. A modern lemezek sajat hibakezelessel 
rendelkeznek, tehat a valaha pl BSD-n is ismert es hasznalt bad144 meg 
ilyesmi programok mar teljesen haszontalanok, mert ha valami hiba mar 
kifele is latszik, vagyis egy ilyen program talal bad blockot, akkor az 
azt jelenti, hogy a lemez tartalekai mar elfogytak, ezert bizony ki kell 
cserelni, ott mar nincs mit cicozni) Ez lehet egy modszer, de szerintem 
a mai lemez elektronikak mellett mar nincs akkora jelentosege, mint 
regen volt. (Regen meg a windowsos lemezutility-k is kerestek bad 
blockokat egyebkent)

Ami nem vilagos szamomra, az az, hogy a grc-s program allandoan fut-e a 
hatterben. A leiras bizonyos reszei ezt sejtetik, de nem torvenyszeru. 
Ha ez igaz, akkor szerintem a folyamatos irogatasaval igenis hozzajarul 
a lemez gyorsabb kopasahoz legalabbis mechanikailag. Ha csak idonkent 
fut le, akkor meg nem fog igazan automatikusan jelezni, mert elobb 
eszedbe kell, hogy jusson, hogy futtasd.

Miutan megneztem azt is, hogy mit ir a rendszerhelyreallito 
kepessegeirol, a kep meg erdekesebb. Az a gyanum, hogy ez a program 
valami nagyon regi technologian alapszik, amikor meg effektive 
lehetseges volt kozvetlenul hozzaferni a lemezelektronikahoz. Ezt 
erositi a Richard O'Reilly (nem a hires konyvkiado) idezet is a lapon:

"After testing SpinRite, I am convinced that it is a must-have product 
for most users of IBM or compatible PC's with hard disks. SpinRite may 
well be the best investment you can make in the integrity of your system."

Hat ugy elso ranezesre ez az idezet kb 1990 korulrol lehet valo, kb 
akkor neveztek utoljara a PC-t "IBM or compatible"-nek. Akkor ezek a 
dolgok meg mind igazak voltak.

> Tovabba eleg, ha gondosan figyelem a logokat, 
> akkor jo esellyel elore tudni fogok a varhato problemarol, vagy tehetek 
> mast is?

A logfigyeles is kell, es ld fenn.

Udv:
Sz.



További információk a(z) BSD levelezőlistáról