I dati su un disco rigido possono degradare senza che Windows mi avverta che ciò è accaduto quando tento di accedere ai dati?


30

È probabile che un degrado fisico di un disco rigido possa causare "capovolgimenti" dei bit nel contenuto del file senza che il sistema operativo "se ne accorga" e che ne parli durante la lettura del file? ad esempio una 'p' in un file di testo ASCII (binario 0111000 0 ) può cambiare in una 'q' (0111000 1 ) e quindi un utente (me) può aprire il file e vedere 'q' senza essere consapevole che un errore è successo?

Sono interessato a risposte relative a FAT, NTFS o ReFS ... se fa la differenza.

Voglio sapere se il sistema operativo mi protegge da questo, o se dovrei controllare i miei dati per invarianza tra le copie / nel tempo.


Non specificamente correlato, ma simile: superuser.com/questions/613702/…
Michael Frank,

Suppongo che potrebbe essere possibile che una testina di lettura / scrittura danneggiata applichi accidentalmente una carica errata al disco, anche se non ho mai visto la corruzione dei dati su una scala così piccola. Inoltre, non mi fiderei di Windows che mi dicesse se un'unità non funziona o meno (il messaggio all'accesso). Ho visto le unità morire lentamente nel tempo senza alcun preavviso da Windows.
CConard96,

Naturalmente ... i dati vengono memorizzati come bit con valori relativi di 0 o 1, l'entropia si verifica in tutti i sistemi, inclusa la memorizzazione magnetica e allo stato solido. Tutti i dati si deteriorano nel tempo.
acejavelin,

2
@Moab: sarei più colpito dal tuo secondo commento ("Anche ...") se l'URL fosse, in qualche modo, diverso dall'URL nel tuo primo commento.
TOOGAM,

1
Se si utilizza ReFS su un volume con mirroring (non parità!) E lo si configura correttamente, verranno verificati i dati del file di checksum e i metadati del file system. Sarà verificato in lettura (e riparato se necessario) e c'è anche un lavoro pianificato che scansionerà periodicamente l'intero volume per rilevare errori.
davidbak,

Risposte:


24

, esiste una cosa chiamata bit rot.

Ma no , non ti influenzerà inosservato.

Quando un'unità 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 e aggiunge codici ECC, che gli consentono di riparare errori che incidono su alcuni bit e di rilevare errori che interessano più di alcuni bit.

Quando l'unità legge il settore, controlla questi codici ECC e ripara i dati, se necessario e possibile. Quello che succede dopo dipende dalle circostanze e dal firmware dell'unità, che è influenzato dalla designazione dell'unità.

  • Se un settore può essere letto e non ha problemi ECC, viene passato al sistema operativo
  • Se un settore può essere riparato facilmente, la versione riparata può essere scritta su disco, riletta e verificata, per determinare se l'errore era casuale (raggi cosmici ...) o se c'è un errore sistematico con il supporto
  • Se l'unità determina che c'è 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'unità designata come unità RAID , l'unità 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 sull'unità guasta, che quindi lo memorizza nel settore riallocato che si spera non abbia il problema.
  • Se un settore non può essere letto o corretto su un'unità desktop , l'unità farà molti più tentativi di leggerlo. A seconda della qualità dell'unità, 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, l'unità riallocherà il settore e riscriverà i dati riparati.

(Questa è una delle principali differenze tra le unità vendute come unità "Desktop", "NAS / RAID" o "Videosorveglianza". Un'unità RAID può semplicemente arrendersi rapidamente e fare riparare il settore dal controller per evitare la latenza sul lato utente. Un'unità desktop riproverà ancora e ancora, perché avere l'utente in attesa di alcuni secondi è probabilmente meglio che dire loro che i dati sono persi. E un'unità video valorizza una velocità di dati costante più del recupero degli errori, poiché un frame danneggiato in genere vince nemmeno essere notato.)

Ad ogni modo, l'unità 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 dirà al sistema operativo. Quindi, spetta al sistema operativo presentare questo errore all'utente e agire su di esso. Ecco perché dice Cybernard

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

l'unità saprà che c'è qualcosa che non va nel settore, ma non sa quali bit hanno fallito. (Un singolo bit che ha fallito verrà sempre rilevato da ECC).

Si prega di notare che il chkdsk, e riparare automaticamente i file system, non l'indirizzo reparing di dati all'interno di file. Questi sono mirati alla corruzione all'interno della struttura del filesystem; come una dimensione del file che differisce tra la voce della directory e il numero di blocchi allocati. La funzione di auto-guarigione di NTFS rileverà danni strutturali e impedirà loro di influenzare ulteriormente i tuoi dati, non riparerà alcun dato che è già danneggiato.

Esistono, naturalmente, altri motivi per cui i dati possono essere danneggiati. Per esempio. RAM errata su un controller può alterare i dati prima ancora che vengano inviati all'unità. In tal caso, nessun meccanismo sull'unità rileverà o riparerà i dati e questo potrebbe essere uno dei motivi per cui la struttura di un filesystem è danneggiata. Altre ragioni includono semplici bug del software, blackout durante la scrittura del disco (anche se questo è affrontato dal journaling del filesystem) o driver di file system errati (il driver NTFS su Linux è diventato di default di sola lettura per molto tempo, poiché NTFS era progettato in modo inverso, 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 diversi data center, per mantenere una copia funzionante se i dati in ogni circostanza. Dopo alcuni mesi, abbiamo notato che su una delle copie, circa lo 0,1% di tutti i file non corrispondeva alla somma MD5 memorizzata dall'applicazione 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 filesystem, come ZFS, conservano ulteriori informazioni di checksum per rilevare errori. Sono progettati per proteggerti da molte più cose che possono andare storte rispetto alla semplice putrefazione.


2
+1 per indicare che altri problemi hardware oltre al degrado dei supporti di unità possono causare la lettura e la scrittura di dati danneggiati . Personalmente ho avuto il problema con cavi difettosi all'interno di un caso. Inoltre, oltre a ZFS, il file system ReFS di Windows (per Server 2012+), se configurato correttamente e in esecuzione su Spazi di archiviazione, eseguirà il checksum dei dati dei file e dei metadati del file system e li ripristinerà, inoltre eseguirà periodicamente l'intero volume scansioni di integrità per rilevare e correggere molti di questi errori.
davidbak,

17

Sì, i dischi rigidi possono degradarsi senza preavviso dal sistema operativo. Si chiama bit putrefazione . Non ho mai assistito a un singolo errore, ma ho visto molti dischi rigidi in cui interi settori hanno fallito.

Windows non ha una protezione integrata del contenuto del file oltre la struttura del filesystem NTFS. Pensa a NTFS come a un libro: beh, protegge solo il sommario e verifica che le cose coincidano. Tuttavia, se il danno si trova nel mezzo di una pagina, non offre alcuna protezione. Il FAT non ha nulla. I dischi rigidi utilizzano la correzione degli errori ECC su base settoriale, ma l'unità non lo dice a Windows. Alcuni tipi di file hanno specificamente hash CRC, MD5 o SHA per rilevare la corruzione, ma non risolvono nulla.

Anche allora l'hash ti dice solo che c'è un problema, ma non sa dove si trova l'errore.

Il disco rigido ha SMART che monitora lo stato del disco rigido, ma a meno che l'unità non si trovi sulla porta della morte, il BIOS non ti avviserà. Peggio ancora, SMART è spesso disabilitata per impostazione predefinita nel BIOS. È possibile monitorare i numeri tramite software, ma unità diverse hanno problemi diversi. Se hai un sacco di settori trasferiti o i tuoi errori ECC aumentano costantemente. Se hai 100.000 nuovi ECC ogni giorno, è un brutto segno.

Molti tipi di file non hanno protezione contro il bit rot . Ad esempio, TXT e BMP, che non hanno alcuna protezione. Winrar ha un'opzione opzionale per aggiungere dati di parità all'archivio che renderà il file più grande, ma può rilevare (proporzionale alla quantità di dati di parità aggiunti) e riparare questo tipo di errore.

Tutti gli altri programmi di compressione che conosco rilevano errori, ma non sono in grado di fare nulla al riguardo.

Alla fine, gli errori in un settore saranno così cattivi che ECC non può correggerlo e l'unità ti darà ciò che legge anche se è sbagliato.

È possibile utilizzare QuickPar o simili per creare file di dati di parità, ma per quanto ne so non c'è modo di automatizzarli. Ad esempio, si modifica il file da soli quando è necessario aggiornare manualmente la parità. È inoltre possibile disporre di dati di parità per un gruppo di file, ma si modifica 1 file e è necessario ricreare l'intero set di parità. Questo è un vero mal di testa per tutti, ma un piccolo numero di file.


Windows, chdsk e NTFS hanno rilevamenti contro il bit rot, che è gestito da RAID o un file system con parità. Una partizione errata non è né è causata dal bit rot.
Approvo

1
@Ramhound Purtroppo, il numero di utenti che proteggono i loro dati con mirroring RAID, livello 5 o livello 6 è probabilmente inferiore allo 0,01%
cybernard

So che stavo parlando in generale. Bit rot! = Partizioni sbagliate
Ramhound,

1
NOR = NOT OR; usato in una frase significa che è un elenco esclusivo;
Ramhound,

1
Ho avuto questo disco rigido da 750 GB che ha fatto cose del genere. Innanzitutto il computer era lento e si blocca continuamente. Quando ho alcuni file di testo, parte di esso viene azzerato o è stato confuso. Successivamente il computer ha smesso di avviarsi. Ho un nuovo disco rigido (ho avuto un HDD non SSD. Penso che avrei dovuto avere un SSD) e il problema è andato e il PC è veloce
Suici Doga,

2

Sì, è possibile. Windows è solo un software. Il software è una serie di istruzioni che un computer deve seguire.

Pensa a un altro tipo di una serie di istruzioni: un libro. Cosa possono realizzare queste istruzioni se sono scritte in un libro che si trova su uno scaffale e nessuno si preoccupa di aprire il libro e leggere quelle istruzioni?

Proprio come quelle istruzioni scritte richiedono a una persona di leggere le istruzioni e iniziare a seguire le istruzioni, il software per computer richiede che l'hardware faccia cose per essere utile. Anche se un libro ha istruzioni che sono state scritte con una precisione favolosa, ciò non impedisce problemi se una persona decide di leggere le istruzioni ma poi di implementarle in modo errato. Allo stesso modo, il software non può impedire all'hardware di fare cose cattive. Quindi, l'hardware rotto può trionfare fisicamente su ciò che può fare qualsiasi software, incluso Microsoft Windows.

Ora, ReFS può essere progettato con l'intento che il software memorizzerà i dettagli sui dati e che il software li confronterà successivamente. Un concetto semplice è "checksum", in cui il software aggiunge determinati valori e si assicura che tali valori corrispondano al risultato previsto. Quando l'hardware implementa quel software, è possibile che vengano rilevati alcuni risultati negativi. Questo potrebbe anche essere altamente probabile che funzioni. Tuttavia, poiché il numero di potenziali problemi, che potrebbero teoricamente esistere, è sostanzialmente un numero infinito, non vi è alcuna garanzia che il software rileverà necessariamente ogni singolo problema. (Tieni presente che il software è una serie di istruzioni che è stata creata in anticipo.)

FAT è particolarmente carente di funzionalità. FAT12 è stato progettato per floppy disk e FAT16 per sistemi fino a 4 GB (sebbene la maggior parte dell'implementazione Microsoft di FAT16 tendesse a non funzionare oltre i 2 GB). Senza l'estensione VFAT, nessuno dei due supportava nomi di file più lunghi di 11 caratteri (alcuni dei quali sarebbero in una porzione chiamata "estensione"). Il FAT è stato semplicemente progettato per archiviare i dati in un momento in cui la capacità di archiviare i dati era un nuovo concetto di cui gli adulti avevano bisogno di essere istruiti. Quando la FAT era considerata una tecnologia "all'avanguardia", la tecnologia informatica non era ancora sufficientemente diffusa ed elaborata per le persone che si preoccupavano delle funzionalità avanzate.

NTFS ha aggiunto il supporto per alcune funzionalità aggiuntive, forse in particolare perché il sistema operativo è in grado di tenere facilmente traccia delle autorizzazioni dell'utente. Esistono diverse versioni di NTFS. Ad esempio, Moab sottolinea che Windows Server 2008 ha aggiunto il supporto per NTFS autorigenerante, che potrebbe rilevare alcune cose. Tuttavia, questa funzionalità era una novità di Windows Server 2008, quindi non è supportata da Windows XP (o Windows Server 2003 o versioni precedenti). Anche ancora, guardando l'elenco delle funzionalità, sembra che questo abbia coinvolto alcuni metadati che aiutano il sistema operativo a notare problemi così gravi che il disco non può essere montato o altre aree chiave del disco che influenzano il kernel del sistema operativo. Non sembrava che ogni singolo dato, in ogni singolo file, venisse influenzato da questa caratteristica particolare.

È estremamente improbabile che il software per tali sistemi operativi noti tali cose, a meno che non causino notevoli problemi al sistema operativo per eseguire le attività. Potrebbero esserci alcune eccezioni, come le parti del sistema operativo che controllano i dischi (CheckDsk / ChkDsk / ScanDisk / ScanDskW, a seconda del sistema operativo), ma anche saranno piuttosto limitati su ciò che possono rilevare, in gran parte perché i filesystem don immagazzinare una grande quantità di dati che era utile per il controllo del disco.

(RAID5 potrebbe essere più incline a rilevare tali cose, con ogni bit con un bit di parità che aiuterebbe a notare qualcosa di insolito. Anche in questo caso, sarebbe opportuno che l'implementazione RAID eseguisse un controllo per notare il problema. Se il problema si verificava una parte del disco su cui non si lavora attivamente, il problema potrebbe rimanere inosservato fino a quando qualcuno non tenta di iniziare a utilizzare tali dati.)

In tempi più recenti, un numero maggiore di bit ha comportato una maggiore probabilità che piccole probabilità, come le probabilità di "1 su 10 milioni", influenzino le cose. Il grande pubblico ha anche imparato a conoscere i "raggi cosmici", che possono avere un piccolo impatto sulle cose. Poiché i bit vengono stipati in modo così stretto nei dispositivi più recenti, i requisiti fisici per rappresentare un bit sono più piccoli, quindi anche i piccoli impatti hanno maggiori probabilità di confondere il modo in cui un bit viene riconosciuto. ReFS ha alcune funzionalità progettate per facilitare il rilevamento. L'articolo di Wikipedia su ReFS si riferisce a questo come "controllo automatico dell'integrità". Dato che viene descritta come una caratteristica notevole di questo filesystem, tali funzioni sono probabilmente più sviluppate rispetto a NTFS (e certamente più di FAT, che era relativamente semplice in natura,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.