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 smettere di GIF animate di giocare nel tuo browser Web

Le GIF animate possono essere un modo divertente per aumentare le reazioni sui social media, o ottenere un punto in un articolo, ma possono anche essere fastidioso, e prendere per sempre per caricare se si dispone di una connessione lenta. Se preferisci non vederli, ecco come impedirgli di animare automaticamente.

(how-to)

Come creare una lista dei tuoi programmi installati su Windows

La reinstallazione di Windows è un buon modo per risolvere problemi seri con il tuo computer, o semplicemente per ottenere una nuova lavagna. Ma prima di reinstallare Windows, dovresti creare un elenco di programmi che hai attualmente installato sul tuo PC in modo da sapere cosa vuoi reinstallare sul nuovo sistema.

(how-to)