Voivatko kiintolevyjä koskevat tiedot hajota ilman varoitusta vahingosta?

Olemme kaikki huolissamme tietojen ja tiedostojen säilyttämisestä turvallisina ja ehjinä, mutta onko mahdollista, että käyttäjä vahingoittuu ja että käyttäjä pääsee käsiksi ilman ilmoitusta tai varoitusta ongelmasta? Tämän päivän SuperUser Q&A -postissa on vastaus huolestuneeseen lukijakysymykseen.

Nykypäivän Kysymys- ja vastaus -istunto tulee meille suotuisasti SuperUserin - Stack Exchange -alueen, yhteisöpohjaisen Q & A-sivustojen ryhmittymän - kautta..

Kuva yleiskuvauksesta (Flickr).

Kysymys

SuperUser-lukija topo morto haluaa tietää, voivatko kiintolevyjen tiedot hajota ja saada tietoja ilman varoitusta vahingoista:

Onko mahdollista, että kiintolevyn fyysinen hajoaminen voi aiheuttaa bittien "kääntymisen" tiedoston sisältöön ilman, että käyttöjärjestelmä huomaa muutosta ja ilmoittaa käyttäjälle siitä, kun tiedostoa luetaan? Voiko esimerkiksi "p" (binäärinen 01110000) ASCII-tekstitiedostossa muuttua "q" (binäärinen 01110001), sitten kun käyttäjä avaa tiedoston, he näkevät "q": n tietämättä, että virhe on tapahtunut?

Olen kiinnostunut vastauksista, jotka liittyvät FAT: ään, NTFS: ään tai ReFS: ään (jos se tekee eron). Haluan tietää, suojelevatko käyttöjärjestelmät käyttäjiä tästä, tai jos meidän pitäisi tarkistaa tiedot kopioiden välillä olevista vaihteluista ajan kuluessa.

Voidaanko kiintolevyjä koskevat tiedot hajota ja käyttää niitä ilman varoitusta vahingoista?

Vastaus

SuperUserin avustaja Guntram Blohmilla on vastaus meille:

Kyllä, on olemassa asia nimeltä bit rot. Mutta ei, se ei vaikuta käyttäjään huomaamatta.

Kun kiintolevy kirjoittaa sektorin levyihin, se ei vain kirjoita bittejä samalla tavalla kuin ne tallennetaan RAM-muistiin, se käyttää koodausta varmistaakseen, ettei yhtään samaa bittiä ole liian kauan. Se lisää myös ECC-koodeja, joiden avulla se voi korjata muutamia bittejä aiheuttavia virheitä ja havaita virheitä, jotka vaikuttavat enemmän kuin muutamaan bittiin.

Kun kiintolevy lukee sektorin, se tarkistaa nämä ECC-koodit ja korjaa tiedot tarvittaessa (ja jos mahdollista). Seuraava riippuu kiintolevyn olosuhteista ja laiteohjelmistosta, johon taajuusmuuttajan nimeäminen vaikuttaa.

• Jos sektoria voidaan lukea ja sillä ei ole ECC-koodiohjeita, se välitetään käyttöjärjestelmälle.
• Jos sektoria voidaan korjata helposti, korjattu versio voidaan kirjoittaa levylle, lukea takaisin, tarkistaa sitten, onko virhe satunnainen (ts. Kosmiset säteet jne.) Tai onko järjestelmässä virhe järjestelmässä.
• Jos kiintolevy määrittää, että tietovälineessä on virhe, se jakaa sektorin uudelleen.
• Jos sektoria ei voi lukea eikä korjata muutaman lukukerran jälkeen (kiintolevylle, joka on nimetty RAID-kiintolevylle), kiintolevy luopuu, jakaa sektorin uudelleen ja kertoo rekisterinpitäjälle, että ongelma on . Se luottaa RAID-ohjaimeen rekonstruoimaan sektorin muista RAID-jäsenistä ja kirjoittamaan sen takaisin epäonnistuneelle kiintolevylle, joka tallentaa sen uudelleen jaettuun sektoriin (joka toivottavasti ei aiheuta ongelmaa).
• Jos sektoria ei voi lukea tai korjata työpöydän kiintolevyllä, kiintolevy yrittää lukea enemmän. Kiintolevyn laadusta riippuen tämä saattaa tarkoittaa pään sijoittamista uudelleen ja sen tarkistamista, onko bittejä, jotka kääntyvät lukemisen aikana, tarkistaen, mitkä bitit ovat heikoimpia ja muutamia muita asioita. Jos jokin näistä yrityksistä onnistuu, kiintolevy jakaa sektorin uudelleen ja kirjoittaa korjatut tiedot takaisin.

Tämä on yksi tärkeimmistä eroista kiintolevyjen välillä, joita myydään "työpöydällä", "NAS / RAID" tai "videovalvonta". RAID-kiintolevy voi vain luopua nopeasti ja tehdä rekisterinpitäjälle korjauksen, jotta vältetään latenssi käyttäjän puolella. Työpöydän kiintolevy jatkaa yrittämistä uudestaan ​​ja uudestaan, koska käyttäjän odottaminen muutaman sekunnin kuluttua on luultavasti parempi kuin kertoa heille, että tiedot menetetään. Ja videon kiintolevyarvo laskee jatkuvia datanopeuksia enemmän kuin virheen palautus, koska vaurioitunut kehys ei tyypillisesti edes huomaa.

Joka tapauksessa kiintolevy tietää, jos on ollut vähän pyöriä, se yleensä palautuu siitä, ja jos se ei onnistu, se kertoo ohjaimelle, joka puolestaan ​​kertoo kuljettajalle, joka sitten kertoo käyttöjärjestelmälle. Sitten on käyttöjärjestelmän tehtävä esittää virhe käyttäjälle ja toimia siinä. Siksi cybernard sanoo:

• En ole koskaan nähnyt yhtäkään virhettä itseäni, mutta olen nähnyt paljon kiintolevyjä, joissa koko sektori on epäonnistunut.

Kiintolevy tietää, onko alalla jotain vikaa, mutta se ei tiedä, mitkä bitit ovat epäonnistuneet. ECC on aina epäonnistunut yksi bitti.

Huomaa, että chkdsk- ja tiedostojärjestelmät, jotka korjaavat itsensä automaattisesti, eivät käsittele tiedostojen tietojen korjaamista. Nämä kohdistuvat korruptioon itse tiedostojärjestelmän rakenteessa, kuten tiedostojen koon ero hakemistomerkinnän ja allokoitujen lohkojen määrän välillä. NTFS: n itsestään parantava ominaisuus havaitsee rakenteellisia vahinkoja ja estää sen vaikuttamasta datasi edelleen, mutta se ei korjaa tietoja, jotka ovat jo vahingoittuneet.

Tietysti on muitakin syitä, miksi tiedot voivat vahingoittua. Esimerkiksi ohjaimen huono RAM voi muuttaa tietoja ennen kuin se lähetetään jopa kiintolevylle. Tällöin mikään kiintolevyn mekanismi ei tunnista tai korjaa dataa, ja tämä voi olla yksi syy siihen, miksi tiedostojärjestelmän rakenne on vaurioitunut. Muita syitä ovat ohjelmistovirheet, sähkökatkokset kiintolevylle kirjoitettaessa (vaikka tämä on osoitettu tiedostojärjestelmän päivittämällä) tai huonot tiedostojärjestelmien ohjaimet (NTFS-ohjain Linuxissa on oletusarvoisesti lukenut vain pitkään, koska NTFS on muunnettu, ei ole dokumentoitu, ja kehittäjät eivät luottaneet omaan koodiinsa).

• Minulla oli tämä skenaario kerran, kun sovellus tallentaisi kaikki sen tiedostot kahteen eri palvelimeen kahdessa eri datakeskuksessa säilyttääkseen käytettävissä olevan tiedon kopion kaikissa olosuhteissa. Muutaman kuukauden kuluttua huomasimme, että noin 0,1 prosenttia kaikista kopioiduista tiedostoista ei vastannut MD5-tarkistussummaa, jonka sovellus on tallentanut sen tietokantaan. Se osoittautui vialliseksi kuitukaapeliksi palvelimen ja SAN: n välillä.

Nämä muut syyt ovat syy siihen, että jotkin tiedostojärjestelmät, kuten ZFS, pitävät tarkistusmäärätietoja virheiden havaitsemiseksi. Ne on suunniteltu suojaamaan sinua paljon enemmän asioita, jotka voivat mennä pieleen kuin vain vähän rotua.

Onko jotain lisättävää selitykseen? Ääni pois kommenteista. Haluatko lukea lisää vastauksia muilta tech-savvy Stack Exchange -käyttäjiltä? Tutustu koko keskusteluketjuun täällä.