Tutti ci preoccupiamo 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 sul 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.

Foto per gentile concessione di generalising (Flickr).

La Domanda

Il lettore SuperUser topo morto vuole sapere se i dati sui dischi rigidi possono degradarsi e essere accessibili senza un avviso sul danno:

È possibile che il degrado fisico di un disco rigido i bit possono "capovolgere" i 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.

I dati sui dischi rigidi possono degradarsi ed essere accessibili senza un avviso sul danno?

Il Risposta

Il collaboratore di 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 usa una codifica per assicurarsi non ci sono sequenze dello stesso bit troppo lunghe. Aggiunge anche codici ECC che consentono di riparare errori che influiscono su 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 drive.

• Se un settore può essere letto e non ha problemi di 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 è casuale (cioè raggi cosmici, ecc.) O se c'è un errore sistematico con il supporto.
• Se il disco rigido determina 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 che è 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 letti o corretti sul disco fisso di un desktop, quindi il disco rigido si impegnerà in più tentativi di leggerlo. A seconda della qualità del disco rigido, ciò potrebbe comportare il riposizionamento della testina, il controllo per vedere 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 i dischi rigidi venduti come "desktop", "NAS / RAID" o " "hard disk" di 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é avere l'utente aspettare qualche secondo è probabilmente meglio che dire che i dati sono 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 marciume di bit, 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 indirizzano 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 funzionalità di autoriparazione di NTFS rileverà i danni strutturali e impedirà di influenzare ulteriormente i dati, ma non ripara i dati già danneggiati.

Esistono, naturalmente, altri motivi per cui i dati potrebbero danneggiarsi. 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 dall'inserimento nel 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).

• Ho avuto questo scenario una volta in cui un'applicazione avrebbe salvato tutti i suoi file su due server diversi in due diversi data center per mantenere una copia funzionante dei dati disponibile 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 che solo un po 'di marciume.

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

Come ottenere avvisi di deal per qualsiasi prodotto con Slickdeals

Ci sono così tante offerte che spuntano ogni singolo giorno che può essere davvero difficile tenere il passo con tutte loro. Ma c'è un modo semplice per tenere traccia solo dei prodotti che ti interessano e ricevere avvisi nella tua e-mail quando un determinato accordo è attivo. Puoi iscriverti a una manciata di mailing list da più negozi solo così puoi tenere traccia di offerte che suscitano il tuo interesse, ma che possono intasare la tua casella di posta elettronica in un batter d'occhio.

(how-to)

Come usare Geektool per personalizzare il desktop del tuo Mac

Geektool è un programma per l'aggiunta di widget personalizzabili sul desktop del tuo Mac. Geektool funziona quasi interamente su script di shell, che si aggiornano ogni pochi secondi per visualizzare informazioni utili sul desktop. La personalizzazione di Geektool è facilitata dagli script packaged chiamati Geeklets, che possono essere installati rapidamente e non richiedono la conoscenza degli script della shell da utilizzare.

(how-to)