Kas andmed kõvakettade kohta kahjustavad kahjustust ilma hoiatuseta?

Me kõik muretseme oma andmete ja failide ohutu ja puutumatu säilitamise pärast, kuid kas on võimalik, et kasutaja saab andmeid kahjustada ja et kasutaja pääseb ilma probleemi kohta teatamata või hoiatamata? Tänase SuperUser Q&A postituse vastus on mures lugeja küsimusele.

Tänane küsimuste ja vastuste seanss saabub meiega kohtades, kus on SuperUser-Stack Exchange'i alajaotis, kogukondlikult juhitav Q&A veebisaitide rühmitus.

Foto viisakalt üldistada (Flickr).

Küsimus

SuperUser-lugeja topo morto tahab teada, kas kõvakettade andmed võivad halveneda ja pääseda ilma hoiatuseta kahju kohta:

Kas on võimalik, et kõvaketta füüsiline lagunemine võib põhjustada bittide "sisu" failisisu muutmata ilma, et operatsioonisüsteem muutust märkaks ja teavitaks sellest faili lugedes? Näiteks, kas „p” (binaarne 01110000) ASCII-tekstifailis võib muutuda “q” -ks (binaarne 01110001), siis kui kasutaja faili avab, näevad nad “q”, ilma et oleks teadlik, et viga on toimunud?

Olen huvitatud vastustest, mis on seotud FAT, NTFS või ReFS (kui see teeb vahet). Ma tahan teada, kas operatsioonisüsteemid kaitsevad kasutajaid sellest või kui me peaksime kontrollima oma andmeid koopiate vahelise aja jooksul.

Kas kõvaketaste andmed võivad laguneda ja neile pääseda ilma hoiatuseta?

Vastus

SuperUser'i toetaja Guntram Blohmil on meile vastus:

Jah, seal on asi, mida nimetatakse natuke mäda. Aga ei, see ei mõjuta kasutajat märkamata.

Kui kõvaketas kirjutab sektsiooni plaatidele, siis ei kirjuta see lihtsalt bitti samamoodi, nagu need on salvestatud RAM-i, siis kasutab ta kodeeringut, et veenduda, et ühtegi sama bitti ei ole liiga kaua. Samuti lisab see ECC-koodid, mis võimaldavad tal parandada vigu, mis mõjutavad mõnda bitti ja avastada vigu, mis mõjutavad rohkem kui paari bitti.

Kui kõvaketas sektorit loeb, kontrollib see neid ECC koode ja parandab vajadusel andmeid (ja võimaluse korral). Järgmine sõltub kõvaketta oludest ja püsivara, mida mõjutab draivi nimetus.

• Kui sektorit saab lugeda ja sellel ei ole ECC-koodi probleeme, edastatakse see operatsioonisüsteemile.
• Kui sektorit saab kergesti parandada, võib parandatud versiooni kirjutada kettale, lugeda tagasi, seejärel kontrollida, kas viga on juhuslik (s.t kosmilised kiired jne) või kui meedias on süstemaatiline viga.
• Kui kõvaketas tuvastab, et meedias on viga, jaotab ta sektori uuesti.
• Kui sektorit ei saa lugeda ega korrigeerida pärast mõnda lugemiskatset (kõvakettal, mis on määratud RAID-kõvakettaks), loobub kõvaketas sellest sektorist, jaotab sektori ümber ja ütleb kontrollerile, et probleem on olemas . See tugineb RAID-regulaatorile sektori taastamiseks teistest RAID-liikmetest ja kirjutab selle tagasi ebaõnnestunud kõvakettale, mis seejärel salvestab selle ümberjaotatud sektorisse (mis loodetavasti ei oma probleemi).
• Kui sektorit ei saa töölaua kõvakettal lugeda või korrigeerida, siis kõvaketas püüab seda rohkem lugeda. Sõltuvalt kõvaketta kvaliteedist võib see hõlmata pea ümberpaigutamist, kontrollimist, et näha, kas lugeda korduvalt lugusid, mis kontrollivad, millised bitid on kõige nõrgemad ja mõned muud asjad. Kui mõni neist katsetest õnnestub, jaotab kõvaketas sektori ümber ja kirjutab parandatud andmed tagasi.

See on üks peamisi erinevusi kõvakettade vahel, mida müüakse “desktop”, “NAS / RAID” või “videovalve” kõvakettadena. RAID-kõvaketas võib lihtsalt loobuda kiiresti ja muuta töötleja sektori parandamiseks, et vältida kasutaja poolset latentsust. Töölaua kõvaketas jätkab ikka ja jälle proovimist, sest kasutaja ootamine paar sekundit on ilmselt parem kui nende andmete kadumine. Ja video kõvaketas hindab konstantseid andmeedastuskiirusi rohkem kui vea taastamine, kuna kahjustatud raami ei täheldata tavaliselt.

Igal juhul teab kõvaketas, kas on olnud natuke mädanenud, tavaliselt taastub, ja kui see ei õnnestu, ütleb ta kontrollerile, kes omakorda ütleb juhtile, kes seejärel operatsioonisüsteemile räägib. Seejärel peab operatsioonisüsteem esitama kasutajale vea ja tegutsema. Sellepärast ütleb cybernard:

• Ma ei ole kunagi näinud ühtegi viga, kuid ma olen näinud palju kõvaketasid, kus terve sektor on ebaõnnestunud.

Kõvaketas teab, kas sektoris on midagi valesti, kuid see ei tea, millised bitid on ebaõnnestunud. ECC püüab alati ebaõnnestunud ühe biti.

Pange tähele, et chkdsk ja failisüsteemid, mis ise parandavad, ei käsitle failide parandamist. Need on suunatud korruptsioonile failisüsteemi enda struktuuris, nagu näiteks faili suuruse vahe kataloogikirje ja eraldatud plokkide arvu vahel. NTFS-i enesetervendav funktsioon tuvastab struktuurset kahju ja takistab selle mõjutamast teie andmeid veelgi, kuid see ei paranda juba kahjustatud andmeid.

Loomulikult on muid põhjusi, miks andmed võivad kahjustuda. Näiteks võib kontrolleri halb RAM muuta andmeid enne, kui see isegi kõvakettale saadetakse. Sellisel juhul ei tuvasta ega paranda ükski kõvaketta mehhanism andmeid ning see võib olla üks põhjus, miks failisüsteemi struktuur on kahjustatud. Muudel põhjustel on tarkvaravead, kõvakettale kirjutamise ajal tekkinud elektrikatkestused (kuigi seda on käsitletud failisüsteemi ajakirjanduse abil) või halbade failisüsteemide draiverid (NTFS-draiver Linuxis on vaikimisi lugenud ainult pikka aega, kuna NTFS on ümber ehitatud dokumenteerimata ja arendajad ei usaldanud oma koodi).

• Mul oli see stsenaarium üks kord, kui rakendus salvestaks kõik oma failid kahesse erinevasse serverisse kahes erinevas andmekeskuses, et hoida kõigis tingimustes kättesaadavatest andmetest koopia. Mõne kuu pärast märkasime, et umbes 0,1 protsenti kõigist kopeeritud failidest ei vastanud MD5 kontrollsummale, mida rakendus oma andmebaasis salvestas. Selgus, et see on vigane kiudkaabel serveri ja SAN vahel.

Need muud põhjused on põhjuseks, miks mõned failisüsteemid, nagu ZFS, hoiavad vigade tuvastamiseks täiendavat kontrollsummat. Need on mõeldud selleks, et kaitsta teid palju rohkem asju, mis võivad valesti minna kui lihtsalt natuke mäda.

Kas teil on midagi lisada selgitusele? Heli on kommentaarides välja lülitatud. Kas soovite lugeda rohkem vastuseid teistelt tech-savvy Stack Exchange'i kasutajatelt? Vaadake siin täielikku arutelu lõiku.