Il bit rot su hard disk è un vero problema? Cosa si può fare al riguardo?

Un amico sta parlando con me del problema dei bit rot - bit sui drive che lanciano casualmente, corrompendo i dati. Incredibilmente raro, ma con abbastanza tempo potrebbe essere un problema ed è impossibile da rilevare.

L'unità non lo considererebbe un settore danneggiato e i backup penserebbero che il file sia cambiato. Non è previsto alcun checksum per convalidare l'integrità. Anche in una configurazione RAID, la differenza sarebbe rilevata ma non ci sarebbe modo di sapere quale copia mirror è corretta.

È un vero problema? E se sì, cosa si può fare al riguardo? Il mio amico sta raccomandando zfs come soluzione, ma non riesco a immaginare di appiattire i nostri file server al lavoro, mettendo su Solaris e zfs ..

Prima di tutto: il tuo file system potrebbe non avere checksum, ma il disco rigido stesso li ha. C'è SMART, per esempio. Una volta che ne sono state capovolte troppe, ovviamente l'errore non può essere corretto. E se sei davvero sfortunato, i bit possono cambiare in modo tale che il checksum non diventerà invalido; quindi l'errore non verrà nemmeno rilevato. Quindi possono succedere cose brutte ; ma l'affermazione che un lancio casuale di bit danneggerà istantaneamente i tuoi dati è falsa.

Tuttavia, sì, quando metti trilioni di bit su un disco rigido, non rimarranno così per sempre; è un vero problema! ZFS può eseguire il controllo di integrità ogni volta che vengono letti i dati; questo è simile a quello che fa già il tuo disco rigido, ma è un'altra protezione per cui stai sacrificando un po 'di spazio, quindi stai aumentando la resilienza contro la corruzione dei dati.

Quando il tuo file system è abbastanza buono, la probabilità che si verifichi un errore senza essere rilevato diventa così bassa che non devi più preoccupartene e potresti decidere che avere checksum integrati nel formato di archiviazione dei dati che stai utilizzando è non necessario.

Ad ogni modo: no, non è impossibile da rilevare .

Ma un file system, da solo, non può mai essere una garanzia da cui ogni errore può essere recuperato; non è un proiettile d'argento. È necessario disporre di backup e un piano / algoritmo per cosa fare quando viene rilevato un errore.

Sì, è un problema, soprattutto quando le dimensioni dell'unità aumentano. La maggior parte delle unità SATA ha una frequenza URE (errore di lettura non correggibile) di 10 ^ 14. O per ogni 12 TB di dati letti statisticamente, il fornitore dell'unità afferma che l'unità restituirà un errore di lettura (normalmente è possibile cercarli sui fogli delle specifiche dell'unità). L'unità continuerà a funzionare perfettamente per tutte le altre parti dell'unità. Le unità Enterprise FC e SCSI hanno generalmente una frequenza URE di 10 ^ 15 (120TB) insieme a un piccolo numero di unità SATA che aiuta a ridurla.

Non ho mai visto i dischi smettere di ruotare nello stesso momento, ma ho avuto un volume raid5 colpito a questo problema (5 anni fa con unità PATA consumer 5400 RPM). L'unità non funziona, è contrassegnata come morta e si verifica una ricostruzione sull'unità di riserva. Il problema è che durante la ricostruzione una seconda unità non è in grado di leggere quel piccolo blocco di dati. A seconda di chi fa il raid, l'intero volume potrebbe essere morto o solo quel piccolo blocco potrebbe essere morto. Supponendo che sia solo che un blocco è morto, se si tenta di leggerlo si otterrà un errore ma se si scrive su di esso l'unità lo rimappa in un'altra posizione.

Esistono diversi metodi per proteggersi da: raid6 (o equivalente) che protegge dai guasti del doppio disco è la cosa migliore, quelli aggiuntivi sono un filesystem che riconosce URE come ZFS, usando gruppi di raid più piccoli così statisticamente che hai una probabilità minore di colpire l'unità URE limiti (mirroring di unità di grandi dimensioni o raid5 unità più piccole), pulizia del disco e SMART aiuta anche, ma non è in realtà una protezione in sé, ma utilizzata in aggiunta a uno dei metodi di cui sopra.

Riesco a gestire quasi 3000 fusi negli array e gli array puliscono costantemente le unità alla ricerca di URE latenti. E ricevo un flusso abbastanza costante di loro (ogni volta che ne trova uno lo risolve prima del guasto dell'unità e mi avvisa), se stavo usando raid5 anziché raid6 e una delle unità fosse completamente morta ... essere nei guai se colpisce determinate posizioni.

I dischi rigidi generalmente non codificano i bit di dati come singoli domini magnetici: i produttori di dischi rigidi sono sempre stati consapevoli del fatto che i domini magnetici potrebbero capovolgersi e incorporare il rilevamento degli errori e la correzione delle unità.

Se si ribalta un po ', l'unità contiene abbastanza dati ridondanti che può e sarà corretta alla successiva lettura di quel settore. Puoi vederlo se controlli le statistiche SMART sull'unità, come "Tasso di errore correggibile".

A seconda dei dettagli dell'unità, dovrebbe anche essere in grado di recuperare da più di un bit capovolto in un settore. Ci sarà un limite al numero di bit capovolti che possono essere corretti silenziosamente e probabilmente un altro limite al numero di bit capovolti che possono essere rilevati come errore (anche se non ci sono più dati affidabili sufficienti per correggerlo)

Tutto ciò si aggiunge al fatto che i dischi rigidi possono correggere automaticamente la maggior parte degli errori mentre si verificano e possono rilevare in modo affidabile la maggior parte degli altri. Dovresti avere un gran numero di errori di bit in un singolo settore, che si sono verificati tutti prima che quel settore venisse letto di nuovo, e gli errori dovrebbero essere tali che i codici di rilevamento degli errori interni lo vedano di nuovo come dati validi, prima di te avrebbe mai avuto un fallimento silenzioso. Non è impossibile e sono sicuro che le aziende che gestiscono data center di grandi dimensioni lo vedono accadere (o meglio, si verifica e non lo vedono accadere), ma non è certamente un problema così grande come potresti pensare.

I dischi rigidi moderni (dal 199x) hanno non solo checksum ma anche ECC, che può rilevare e correggere un po 'di marcio "casuale". Vedi: http://en.wikipedia.org/wiki/SMART .

D'altra parte, alcuni bug nel firmware e nei driver di dispositivo possono anche corrompere i dati in rare occasioni (altrimenti il ​​QA catturerebbe i bug) che sarebbe difficile da rilevare se non si hanno checksum di livello superiore. I primi driver di dispositivo per SATA e NIC avevano dati corrotti su Linux e Solaris.

I checksum ZFS mirano principalmente ai bug nel software di livello inferiore. I sistemi di archiviazione / database più recenti come Hypertable hanno anche checksum per ogni aggiornamento per evitare bug nei filesystem :)

Teoricamente, questo è motivo di preoccupazione. In pratica, questo fa parte del motivo per cui conserviamo backup figlio / genitore / nonno. I backup annuali devono essere conservati per almeno 5 anni, IMO, e se hai un caso che risale a questo, il file non è ovviamente così importante.

A meno che tu non abbia a che fare con bit che potrebbero potenzialmente liquidare il cervello di qualcuno , non sono sicuro che il rischio contro la ricompensa sia abbastanza fino al punto di cambiare i file system.

Sì, è un problema.

Questo è uno dei motivi per cui RAID6 è ora in voga (oltre ad aumentare le dimensioni dell'HD aumenta il tempo per ricostruire un array). Avere due blocchi di parità consente un backup aggiuntivo.

I sistemi RAID ora eseguono anche RAID Scrubbing che legge periodicamente blocchi del disco, verifica le parità e lo sostituisce se trova un blocco difettoso.

Per quanto riguarda l'affermazione del PO su RAID non capendo quali dati siano buoni o cattivi.

I controller RAID utilizzano almeno bit di parità (pari / dispari) su ogni striscia di dati. Questo è per tutto; le strisce di dati su disco e le strisce di parità (backup).

Ciò significa che per qualsiasi tipo di RAID con striping per ridondanza (RAID 5/6) il controller è in grado di dire con precisione se la striscia di dati originale è cambiata, nonché se la striscia di dati di ridondanza è cambiata.

Se si introduce una seconda striscia ridondante come RAID6, è necessario disporre di 3 strisce di dati, su tre unità diverse danneggiate, che corrispondono tutte agli stessi dati di file effettivi. Ricorda che la maggior parte dei sistemi RAID usa strisce di dati relativamente piccole (128kb o meno), quindi le possibilità del "bit rot" che si allinea allo stesso 128kb, dello stesso file, sono praticamente impossibili.

È un problema del mondo reale, sì, ma la domanda è se dovresti preoccuparti o meno.

Se hai solo un disco pieno di immagini, potrebbe non valere la pena. È pieno di importanti dati scientifici, potrebbe essere un altro tipo di storia, hai avuto l'idea.