I dati sui dischi rigidi possono degradare senza un avviso sui danni?

Siamo tutti preoccupati di mantenere i nostri dati e file al sicuro e intatti, ma è possibile che i dati vengano danneggiati e accessibili da un utente senza notifica o avviso di alcun tipo riguardo al problema? Il post di Q & A di SuperUser di oggi ha la risposta alla domanda di un lettore preoccupato.

La sessione di domande e risposte di oggi ci viene fornita per gentile concessione di SuperUser, una suddivisione di Stack Exchange, un raggruppamento di siti Web di domande e risposte basato sulla comunità.

Foto per gentile concessione di generalising (Flickr).

La domanda

Lettore SuperUser topo morto vuole sapere se i dati sui dischi rigidi possono degradare e accedere senza un avviso sul danno:

È possibile che il degrado fisico di un disco rigido possa causare il "ribaltamento" dei bit nei contenuti di un file senza che il sistema operativo noti la modifica e ne informi l'utente durante la lettura del file? Ad esempio, una "p" (01110000 binario) in un file di testo ASCII diventa "q" (binario 01110001), quindi quando un utente apre il file, viene visualizzato "q" senza essere a conoscenza del verificarsi di un errore?

Sono interessato alle risposte relative a FAT, NTFS o ReFS (se fa la differenza). Voglio sapere se i sistemi operativi proteggono gli utenti da questo, o se dovremmo controllare i nostri dati per le variazioni tra le copie nel tempo.

È possibile degradare e accedere ai dati sui dischi rigidi senza avvertire il danno?

La risposta

Il collaboratore SuperUser Guntram Blohm ha la risposta per noi:

Sì, c'è una cosa chiamata bit rot. Ma no, non influenzerà un utente inosservato.

Quando un disco rigido scrive un settore nei piatti, non si limita a scrivere i bit nello stesso modo in cui sono memorizzati nella RAM, ma utilizza una codifica per assicurarsi che non ci siano sequenze dello stesso bit troppo lunghe. Aggiunge anche codici ECC che consentono di riparare gli errori che interessano alcuni bit e rilevare errori che influiscono su più di pochi bit.

Quando il disco rigido legge il settore, controlla questi codici ECC e ripara i dati se necessario (e se possibile). Quello che succede dopo dipende dalle circostanze e dal firmware del disco rigido, che è influenzato dalla designazione del convertitore.

• Se un settore può essere letto e non ha problemi di codice ECC, viene trasmesso al sistema operativo.
• Se un settore può essere riparato facilmente, la versione riparata può essere scritta su disco, riletta, quindi verificata per determinare se l'errore è casuale (cioè raggi cosmici, ecc.) O se c'è un errore sistematico con i media.
• Se il disco rigido determina che c'è un errore nel supporto, rialloca il settore.
• Se un settore non può essere letto né corretto dopo alcuni tentativi di lettura (su un disco rigido designato come disco rigido RAID), il disco rigido si arrenderà, rialloca il settore e comunica al controller che si è verificato un problema . Si affida al controller RAID per ricostruire il settore dagli altri membri RAID e scriverlo sul disco rigido guasto, che quindi lo memorizza nel settore riallocato (che si spera non abbia un problema).
• Se un settore non può essere letto o corretto sul disco fisso di un desktop, il disco rigido si impegnerà in ulteriori tentativi di lettura. A seconda della qualità del disco rigido, ciò potrebbe comportare il riposizionamento della testina, controllando se ci sono dei bit che si capovolgono quando vengono letti ripetutamente, controllando quali sono i bit più deboli e alcune altre cose. Se uno di questi tentativi riesce, il disco rigido rialloca il settore e riscrive i dati riparati.

Questa è una delle principali differenze tra gli hard disk venduti come hard disk "desktop", "NAS / RAID" o "videosorveglianza". Un disco rigido RAID può semplicemente arrendersi rapidamente e fare in modo che il controller ripari il settore per evitare la latenza dal lato dell'utente. Un disco fisso del desktop continuerà a provare ancora e ancora perché l'attesa dell'utente per alcuni secondi è probabilmente meglio che dire che i dati vanno persi. Inoltre, un disco rigido video stimola la velocità dei dati più che il recupero degli errori, poiché in genere un frame danneggiato non viene nemmeno notato.

In ogni caso, il disco rigido saprà se c'è stato un po 'di marciume, in genere recupererà da esso, e se non può, dirà al controller che a sua volta dirà al guidatore che poi dirà al sistema operativo. Quindi, spetta al sistema operativo presentare l'errore all'utente e agire su di esso. Ecco perché Cybernard dice:

• Non ho mai assistito a un singolo errore, ma ho visto un sacco di dischi rigidi in cui interi settori hanno fallito.

Il disco rigido saprà se c'è qualcosa di sbagliato in un settore, ma non saprà quali bit hanno fallito. Un singolo bit che ha fallito sarà sempre catturato da ECC.

Si noti che chkdsk e file system che si riparano automaticamente non risolvono la riparazione dei dati all'interno dei file. Questi sono mirati alla corruzione all'interno della struttura del file system stesso, come una differenza nella dimensione di un file tra la voce della directory e il numero di blocchi allocati. La funzione di autoriparazione di NTFS rileverà i danni strutturali e impedirà che incida ulteriormente sui tuoi dati, ma non riparerà alcun dato già danneggiato.

Esistono, naturalmente, altri motivi per cui i dati potrebbero essere danneggiati. Ad esempio, una RAM scadente su un controller potrebbe alterare i dati prima che vengano persino inviati al disco rigido. In tal caso, nessun meccanismo sul disco rigido rileverà o riparerà i dati e questo potrebbe essere uno dei motivi per cui la struttura di un file system è danneggiata. Altri motivi includono bug del software, blackout durante la scrittura sul disco rigido (sebbene questo sia indirizzato dal journal del file system) o driver del file system (il driver NTFS su Linux è stato impostato in sola lettura per un lungo periodo da quando è stato eseguito il reverse engineering di NTFS, non documentato, e gli sviluppatori non si fidavano del proprio codice).

• Avevo questo scenario una volta in cui un'applicazione salvava tutti i suoi file su due server diversi in due diversi data center per mantenere una copia funzionante dei dati disponibili in tutte le circostanze. Dopo alcuni mesi, abbiamo notato che circa lo 0,1 percento di tutti i file copiati non corrispondeva alla somma di controllo MD5 che l'applicazione memorizzava nel suo database. Si è rivelato essere un cavo in fibra difettoso tra il server e la SAN.

Questi altri motivi sono il motivo per cui alcuni file system, come ZFS, mantengono ulteriori informazioni sulla somma di controllo al fine di rilevare errori. Sono progettati per proteggerti da molte più cose che possono andare storte rispetto al solo bit put.

Hai qualcosa da aggiungere alla spiegazione? Audio disattivato nei commenti. Vuoi leggere più risposte dagli altri utenti di Stack Exchange esperti di tecnologia? Controlla la discussione completa qui.