Ne facem griji cu privire la păstrarea datelor și fișierelor noastre în siguranță și intacte, dar este posibil ca datele să se deterioreze și să fie accesate de un utilizator fără nicio notificare sau avertizare de orice fel despre această problemă? Postul de astăzi SuperUser Q & A are răspunsul la o întrebare îngrijorată a cititorului.
Sesiunea de întrebări și răspunsuri din ziua de astăzi vine de la amabilitatea SuperUser - o subdiviziune a Stack Exchange, o grupare bazată pe comunitate a site-urilor Q & A.
Fotografie curtoazie de generalizare (Flickr).
Cititorul superușorului topo morto dorește să știe dacă datele de pe hard-discuri se pot degrada și fi accesate fără avertisment despre daune:
Este posibil ca degradarea fizică a unui hard disk să determine ca biții să "răstoarne" conținutul unui fișier fără ca sistemul de operare să observe schimbarea și să notifice utilizatorul despre el atunci când citește fișierul? De exemplu, ar putea fi schimbat un "p" (binar 01110000) într-un fișier text ASCII la un "q" (binar 01110001), atunci când un utilizator deschide fișierul, văd "q" fără să știe că a apărut o eroare?
Sunt interesat de răspunsuri referitoare la FAT, NTFS sau ReFS (dacă face diferența). Vreau să știu dacă sistemele de operare protejează utilizatorii de acest lucru sau dacă ar trebui să verificăm datele noastre pentru diferențele dintre copii în timp.
Poate datele de pe hard-discuri să se degradeze și să fie accesate fără un avertisment despre daune?
Contribuabilul SuperUser Guntram Blohm are răspunsul pentru noi:
Da, există un lucru numit putregai. Dar nu, nu va afecta un utilizator neobservat.
Atunci când un hard disk scrie un sector pe platouri, nu scrie doar biți în același mod în care sunt stocați în RAM, utilizează o codificare pentru a vă asigura că nu există secvențe ale aceluiași bit prea lungi. De asemenea, acesta adaugă coduri ECC care îi permit să repare erorile care afectează câțiva biți și să detecteze erorile care afectează mai mult de câțiva biți.
Atunci când hard-ul citește sectorul, acesta verifică aceste coduri ECC și repară datele, dacă este necesar (și dacă este posibil). Ce se întâmplă în continuare depinde de circumstanțele și de firmware-ul unității hard disk, care este influențată de desemnarea unității.
- Dacă un sector poate fi citit și nu are probleme de cod ECC, acesta este transferat sistemului de operare.
- Dacă un sector poate fi reparat cu ușurință, versiunea reparată poate fi scrisă pe disc, citită înapoi, apoi verificată pentru a determina dacă eroarea a fost una eronată (adică raze cosmice etc.) sau dacă există o eroare sistematică cu suportul media.
- Dacă unitatea hard disc determină existența unei erori cu suportul media, acesta realocă sectorul.
- Dacă un sector nu poate fi citit și nici corectat după câteva încercări de citire (pe un hard disk care este desemnat ca un hard disk RAID), atunci hard diskul va renunța, va realoca sectorul și va spune controlorului că a existat o problemă . Se bazează pe controlerul RAID pentru a reconstrui sectorul de la ceilalți membri ai RAID-ului și a-l scrie înapoi pe un hard disk nereușit, care îl stochează apoi în sectorul realocat (care, sperăm, nu are nicio problemă).
- Dacă un sector nu poate fi citit sau corectat pe un hard disk de pe un desktop, atunci hard diskul se va angaja în mai multe încercări de citire. În funcție de calitatea hard disk-ului, aceasta ar putea implica repoziționarea capului, verificarea pentru a vedea dacă există biți care se răstoarnă atunci când se citesc în mod repetat, verificând care biți sunt cei mai slabi și alte câteva lucruri. Dacă oricare dintre aceste încercări reușește, unitatea hard disk va realoca sectorul și va scrie înapoi datele reparate.
Aceasta este una dintre principalele diferențe dintre unitățile de hard disk care sunt vândute ca hard discuri "desktop", "NAS / RAID" sau "video de supraveghere video". O unitate hard disk RAID poate renunța repede și poate repara controlerul sectorului pentru a evita latența din partea utilizatorului. Un hard disk de pe desktop va continua să încerce din nou și din nou, deoarece așteptarea utilizatorilor câteva secunde este probabil mai bună decât să le spunem că datele sunt pierdute. Și un hard disk video valorează ratele de date constante mai mult decât recuperarea erorilor, deoarece un cadru deteriorat nu va fi de obicei observat.
În orice caz, hard disk-ul va ști dacă a existat putregai, se va recupera în mod obișnuit de la acesta și, dacă nu se poate, va informa controlerul, care la rândul său îi va spune șoferului care va spune apoi sistemul de operare. Apoi, este de datoria sistemului de operare să prezinte eroarea utilizatorului și să acționeze asupra acestuia. Acesta este motivul pentru care cybernard spune:
- Nu am fost niciodată martor la o singură eroare de biți, dar am văzut o mulțime de unități de hard disk în care sectoarele întregi au eșuat.
Hard disk-ul va ști dacă există ceva în neregulă cu un sector, dar nu va ști ce biți au eșuat. Un singur bit care a eșuat va fi întotdeauna prins de ECC.
Rețineți că sistemul chkdsk și fișierele care se repară automat nu se adresează reparării datelor în fișiere. Acestea sunt destinate corupției în structura sistemului de fișiere în sine, ca o diferență în dimensiunea unui fișier între intrarea directorului și numărul de blocuri alocate. Caracteristica de auto-vindecare a NTFS va detecta daune structurale și va împiedica să vă afecteze în continuare datele, dar nu va repara niciun fel de date deja deteriorate.
Există, desigur, și alte motive pentru care datele pot fi deteriorate. De exemplu, memoria RAM necorespunzătoare de pe un controler poate modifica datele înainte ca aceasta să fie chiar trimisă pe hard disk. În acest caz, niciun mecanism de pe hard disk nu va detecta sau repara datele și acesta poate fi un motiv pentru care structura unui sistem de fișiere este deteriorată.Alte motive includ bug-uri de software, întreruperi în timp ce scrieți pe hard disk (deși acest lucru este abordat de jurnal de sistem de fișiere) sau drivere de sistem de fișiere rău (driverul NTFS pe Linux a fost defautat pentru a citi doar pentru o lungă perioadă de timp, nu documentate, iar dezvoltatorii nu au încredere în propriul cod).
- Am avut acest scenariu odată ce o aplicație ar salva toate fișierele sale pe două servere diferite în două centre de date diferite pentru a păstra o copie de lucru a datelor disponibile în toate circumstanțele. După câteva luni, am observat că aproximativ 0,1% din toate fișierele copiate nu se potrivesc cu suma de verificare MD5 pe care aplicația le-a stocat în baza de date. Sa dovedit a fi un cablu de fibre defect între server și SAN.
Aceste alte motive sunt de ce unele sisteme de fișiere, cum ar fi ZFS, păstrează informații de sumă suplimentare de verificare pentru a detecta erorile. Acestea sunt concepute pentru a te proteja de mult mai multe lucruri care pot merge prost decât doar putregaiul.
Aveți ceva de adăugat la explicație? Sunați în comentarii. Doriți să citiți mai multe răspunsuri de la alți utilizatori de tehnologie Stack Exchange? Check out discuția completă aici.
