Ci preoccupiamo tutti di mantenere intatti e sicuri i nostri dati e file, ma è possibile che i dati vengano danneggiati e siano accessibili a un utente senza una notifica o un avviso di alcun tipo sul problema? Il post di domande e risposte di SuperUser di oggi ha la risposta alla domanda di un lettore preoccupato.
La sessione di domande e risposte di oggi ci viene fornita da SuperUser, una suddivisione di Stack Exchange, un raggruppamento di siti Web di domande e risposte guidato dalla community.
Foto per gentile concessione di generalizzazione (Flickr).
La domanda
Il lettore SuperUser topo morto vuole sapere se i dati sui dischi rigidi possono degradarsi ed è possibile accedervi senza un avviso sul danno:
È possibile che il degrado fisico di un disco rigido possa causare il capovolgimento 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” (binaria 01110000) in un file di testo ASCII potrebbe cambiare in una “q” (binaria 01110001), quindi quando un utente apre il file, vedono “q” senza essere consapevoli che si è verificato un errore?
Sono interessato a 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 variazioni nel tempo tra le copie.
I dati sui dischi rigidi possono degradarsi ed è possibile accedervi senza un avviso sul danno?
La risposta
Il collaboratore del SuperUser Guntram Blohm ha la risposta per noi:
Sì, esiste una cosa chiamata bit rot. No, non influenzerà l'utente inosservato.
Quando un disco rigido scrive un settore sui piatti, non solo scrive i bit nello stesso modo in cui sono memorizzati nella RAM, ma utilizza una codifica per assicurarsi che non vi siano sequenze dello stesso bit troppo lunghe. Aggiunge inoltre codici ECC che gli consentono di riparare errori che incidono su alcuni bit e di rilevare errori che interessano più di alcuni 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 disco.
- Se un settore può essere letto e non ha problemi con il codice ECC, viene passato 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 era casuale (ovvero raggi cosmici, ecc.) O se si verifica un errore sistematico con il supporto.
- Se il disco rigido determina che si è verificato un errore con il supporto, rialloca il settore.
- Se un settore non può essere né letto né corretto dopo alcuni tentativi di lettura (su un disco rigido designato come disco rigido RAID), il disco rigido si arrenderà, riallocerà il settore e comunicherà al controller che si è verificato un problema . Si affida al controller RAID per ricostruire il settore dagli altri membri RAID e riscriverlo sul disco rigido guasto, che quindi lo memorizza nel settore riallocato (che si spera non abbia problemi).
- Se un settore non può essere letto o corretto sul disco rigido di un desktop, il disco rigido attiverà più tentativi di leggerlo. A seconda della qualità del disco rigido, ciò potrebbe comportare il riposizionamento della testina, controllando se ci sono bit che si ribaltano quando vengono letti ripetutamente, controllando quali bit sono i più deboli e poche altre cose. Se uno di questi tentativi ha esito positivo, il disco rigido riallocherà il settore e riscriverà i dati riparati.
Questa è una delle principali differenze tra i dischi rigidi venduti come dischi rigidi “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 rigido desktop continuerà a riprovare più volte perché avere l'utente in attesa di alcuni secondi è probabilmente meglio che dire loro che i dati sono persi. E un disco rigido video valorizza velocità di dati costanti più del recupero degli errori poiché un frame danneggiato non viene nemmeno notato.
Ad ogni modo, il disco rigido saprà se c'è stato un po 'di marcio, in genere si riprenderà da esso, e se non ci riuscirà, dirà al controller che a sua volta dirà al driver 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 molti 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 sono falliti. Un singolo bit non riuscito verrà sempre rilevato da ECC.
Si noti che chkdsk e file system che si riparano automaticamente non risolvono i dati di riparazione 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 auto-guarigione di NTFS rileverà danni strutturali e gli impedirà di influenzare ulteriormente i dati, ma non riparerà i dati già danneggiati.
Esistono, naturalmente, altri motivi per cui i dati possono essere danneggiati. Ad esempio, una RAM difettosa su un controller potrebbe alterare i dati prima ancora che vengano 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 (anche se questo è risolto dal journaling del file system) o driver di file system errati (il driver NTFS su Linux è diventato predefinito di sola lettura per molto tempo da quando NTFS è stato retroingegnerizzato, non documentato e gli sviluppatori non si fidavano del proprio codice).
- Una volta ho avuto questo scenario in cui un'applicazione avrebbe salvato tutti i suoi file su due server diversi in due data center diversi al fine di 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 alla semplice putrefazione.
Hai qualcosa da aggiungere alla spiegazione? Audio disattivato nei commenti. Vuoi leggere altre risposte da altri utenti esperti di Stack Exchange? Dai un'occhiata al thread completo di discussione qui.
