rilevamento e correzione del marciume dei bit con mdadm

Sto per riorganizzare tutti i miei HDD nel mio nas box di Linux e vorrei usare mdadm raid per la protezione dei dati e la sua flessibilità per rimodellare gli array. Tuttavia, prima di usare mdadm per questo mi piacerebbe sapere come gestisce il marciume dei bit . In particolare i tipi di bit rot che non comportano l'invio di messaggi di errore di lettura irrecuperabili dall'HDD.

Dato che probabilmente userò almeno 21 TB di HDD in 8 dischi nel nas e le varie citazioni sulle probabilità di guasti sugli HDD, sto pensando che durante una ricostruzione da un singolo errore del disco ho ragionevolmente probabilità di incontrare una qualche forma di marcescenza dei bit sui dischi rimanenti. Se si tratta di un errore di lettura irrecuperabile su 1 delle unità, che l'unità in realtà lo segnala come un errore, credo che dovrebbe andare bene con raid6 (vero?). Tuttavia, se i dati letti dal disco sono errati ma non riportati come tali dal disco, non riesco a vedere come questo possa essere corretto automaticamente anche con raid6. È qualcosa di cui dobbiamo preoccuparci? Visto l'articolo È il 2010 e RAID5 funziona ancorae le mie esperienze di successo a casa e al lavoro, le cose non sono necessariamente così difficili come le parole d'ordine e il marketing ci vorrebbero far credere, ma odio dover ripristinare dai backup solo perché un HDD non è riuscito.

Dato che i modelli di utilizzo saranno, scrivere al massimo alcune volte e leggere occasionalmente, dovrò eseguire lo scrubbing dei dati . Vedo sul wiki di archlinux i comandi mdadm per i dati che puliscono un array come

echo check > /sys/block/md0/md/sync_action

quindi per monitorare l'avanzamento

cat /proc/mdstat

Questo mi sembra che leggerà tutti i settori di tutti i dischi e verificherà che i dati corrispondano alla parità e viceversa. Anche se noto che c'è una forte enfasi nei documenti per dire che ci sono circostanze significative che l'operazione di "controllo" non sarà in grado di correggere automaticamente, rileverà e lascerà all'utente la correzione.

Quali livelli RAID mdadm dovrei scegliere per massimizzare la mia protezione da marciume bit e quali interventi di manutenzione e di protezione dovrei fare? E da cosa non mi proteggerà?

Modifica: non sto cercando di avviare un RAID vs ZFS o qualsiasi altro QA tecnologico. Voglio sapere specificamente del raid di mdadm. Questo è anche il motivo per cui lo sto chiedendo su Unix e Linux e non su SuperUser .

Modifica: è la risposta: mdadm può correggere solo gli URE che vengono segnalati dai sistemi a disco durante uno scrub dei dati e rilevare un marcio di bit silenzioso durante uno scrub ma non è possibile / non risolverlo?

Francamente, trovo piuttosto sorprendente che tu rifiutassi RAIDZ2 ZFS. Sembra soddisfare le tue esigenze quasi perfettamente, tranne per il fatto che non è Linux MD. Non sono in crociata per portare ZFS tra le masse, ma il semplice fatto è che il tuo è uno dei tipi di problemi che ZFS è stato progettato da zero per risolvere. Affidarsi al RAID (qualsiasi RAID "normale" per fornire il rilevamento e la correzione degli errori, possibilmente in una situazione di ridondanza ridotta o assente, sembra rischioso. Anche in situazioni in cui ZFS non è in grado di correggere correttamente un errore di dati, può almeno rilevare l'errore e farti sapere che c'è un problema, consentendoti di intraprendere azioni correttive.

Non è necessario eseguire scrub completi regolari con ZFS, sebbene sia una pratica consigliata. ZFS verificherà che i dati letti dal disco corrispondano a quelli scritti durante la lettura dei dati e in caso di mancata corrispondenza (a) utilizzare la ridondanza per ricostruire i dati originali o (b) segnalare un errore I / O a l'applicazione. Inoltre, lo scrubbing è un'operazione online a bassa priorità, abbastanza diversa da un controllo del file system nella maggior parte dei file system che può essere sia ad alta priorità che offline. Se stai eseguendo uno scrub e qualcosa di diverso dallo scrub vuole fare I / O, lo scrub prenderà il sedile posteriore per la durata. Uno scrub ZFS prende il posto sia di uno scrub RAID che di un metadata del file system e dei dati controllo dell'integrità, quindi è molto più accurato del semplice lavaggio dell'array RAID per rilevare l'eventuale marciume dei bit (il che non ti dice se i dati hanno alcun senso, solo che sono stati scritti correttamente dal controller RAID).

La ridondanza ZFS (RAIDZ, mirroring, ...) ha il vantaggio che non è necessario verificare la coerenza delle posizioni del disco inutilizzate durante gli scrub; durante lo scrub vengono controllati solo i dati effettivi, poiché gli strumenti percorrono la catena di blocchi di allocazione. È lo stesso di un pool non ridondante. Per un RAID "normale", è necessario controllare tutti i dati (comprese eventuali posizioni inutilizzate sul disco) poiché il controller RAID (sia hardware che software) non ha idea di quali dati siano effettivamente rilevanti.

Usando RAIDZ2 vdevs, qualsiasi unità costituente due può guastarsi prima di essere a rischio di perdita effettiva di dati a causa di un altro guasto dell'unità, poiché si ha una ridondanza di due unità. Questo è essenzialmente lo stesso di RAID6.

In ZFS tutti i dati, sia i dati utente che i metadati, vengono sottoposti a checksum (tranne se si sceglie di non farlo, ma è sconsigliato) e questi checksum vengono utilizzati per confermare che i dati non sono stati modificati per nessun motivo. Anche in questo caso, se un checksum non corrisponde al valore previsto, i dati verranno ricostruiti in modo trasparente o verrà segnalato un errore I / O. Se viene segnalato un errore I / O o uno scrub identifica un file corrotto, saprai per certo che i dati in quel file sono potenzialmente corrotti e puoi ripristinare quel file specifico dal backup; non è necessario un ripristino completo dell'array.

Semplice, anche a doppia parità, RAID non ti protegge da situazioni come ad esempio quando un'unità si guasta e un'altra legge i dati in modo errato dal disco. Supponiamo che un'unità si sia guastata e che ci sia un solo capovolgimento in qualsiasi punto rispetto a una qualsiasi delle altre unità: improvvisamente hai una corruzione non rilevata e, a meno che tu non sia soddisfatto, avrai bisogno di un modo per rilevarla. Il modo per mitigare tale rischio è quello di eseguire il checksum di ciascun blocco sul disco e assicurarsi che il checksum non possa essere corrotto insieme ai dati (protezione da errori come scritture high-fly, scritture orfane, scritture in posizioni errate sul disco, ecc.), Che è esattamente ciò che fa ZFS fintanto che il checksum è abilitato.

L'unico aspetto negativo è che non è possibile far crescere facilmente un vdev RAIDZ aggiungendo dispositivi ad esso. Ci sono soluzioni alternative per questo, che di solito coinvolgono cose come file sparsi come dispositivi in ​​un vdev, e molto spesso chiamato "Non lo farei se fossero i miei dati". Quindi, se segui un percorso RAIDZ (indipendentemente dal fatto che tu vada con RAIDZ, RAIDZ2 o RAIDZ3), devi decidere in anticipo quante unità vuoi in ogni vdev. Sebbene il numero di unità in un vdev sia fisso, è possibile far crescere un vdev gradualmente (assicurandosi di rimanere entro la soglia di ridondanza del vdev) sostituendo le unità con unità di maggiore capacità e consentendo un completo resilver.

Questa risposta è il prodotto del ragionamento basato sui vari elementi di prova che ho trovato. Non so come funziona l'implementazione del kernel Linux, dato che non sono un sviluppatore del kernel e sembra che ci sia una discreta quantità di disinformazione senza senso là fuori. Presumo che il kernel Linux compia scelte sane. La mia risposta dovrebbe valere a meno che non mi sbagli.

Molte unità utilizzano ECC (codici di correzione errori) per rilevare errori di lettura. Se i dati sono corrotti, il kernel dovrebbe ricevere un URE (errore di lettura irrecuperabile) per quel blocco da un'unità ECC che supporta. In queste circostanze (e c'è un'eccezione di seguito), copiare dati corrotti o vuoti, equivale a pazzia. In questa situazione il kernel dovrebbe sapere quali sono i dati buoni e quali i dati cattivi. Secondo l'articolo È il 2010 e RAID5 funziona ancora ... articolo:

Considera questa alternativa, che so essere utilizzata da almeno un paio di venditori di array. Quando un'unità in un volume RAID segnala un URE, il controller di array aumenta un conteggio e soddisfa l'I / O ricostruendo il blocco dalla parità. Esegue quindi una riscrittura sul disco che riportava l'URRE (potenzialmente con verifica) e se il settore è danneggiato, il microcodice rimappa e tutto andrà bene.

Tuttavia, ora per l'eccezione: se un'unità non supporta ECC, un'unità risiede nella corruzione dei dati o il firmware è particolarmente disfunzionale, quindi un URE potrebbe non essere segnalato e i dati danneggiati verrebbero forniti al kernel. In caso di mancata corrispondenza dei dati: sembra che se si utilizza un RAID1 a 2 dischi o un RAID5, il kernel non può sapere quali dati sono corretti, anche se in uno stato non degradato, poiché esiste una sola parità blocco e non è stato segnalato alcun URE. In un RAID1 a 3 dischi o RAID6, un singolo blocco non contrassegnato non URE danneggiato non corrisponderebbe alla parità ridondante (in combinazione con gli altri blocchi associati), quindi dovrebbe essere possibile un corretto ripristino automatico.

La morale della storia è: usare le unità con ECC. Sfortunatamente non tutte le unità che supportano ECC pubblicizzano questa funzione. D'altra parte, fai attenzione: conosco qualcuno che ha usato SSD economici in un RAID1 a 2 dischi (o un RAID10 a 2 copie). Una delle unità ha restituito dati danneggiati casuali su ciascuna lettura di un determinato settore. I dati danneggiati sono stati copiati automaticamente sui dati corretti. Se l'SSD utilizzava ECC e funzionava correttamente, il kernel avrebbe dovuto intraprendere le azioni correttive appropriate.

Per la protezione che desideri, preferirei RAID6 + il normale backup offsite in 2 posizioni.

Scrub personalmente una volta alla settimana e backup ogni notte, settimanalmente e mensilmente a seconda dell'importanza dei dati e della velocità di modifica.

Non ho abbastanza rappresentante per commentare, ma voglio sottolineare che il sistema mdadm in Linux NON corregge alcun errore. Se gli dici di "correggere" errori durante uno scrub di, diciamo, RAID6, se c'è un'incoerenza, lo "riparerà" assumendo che le porzioni di dati siano corrette e ricalcolando la parità.

po 'marcire fud.? sicuro...

Immagino che devi parlare con SEAGATE. (dimentica? è questa la scusa)? le unità ora hanno tutte la correzione ECC a 100 bit che è necessario provare prima il marciume.
Scommetto che non puoi. (è cosa FUD preoccuparsi vero?) come la paura dei fantasmi o il # 13? e non fatto qui. nessuna prova è avvenuta. e peggio ancora nessuna prova di causa.

Per prima cosa definire cosa significa bit rot. ahi ... HDD: ECC controlla i dati (anche 1 bit) rispetto alla memoria ECC a 100 bit. se è sbagliato, lo corregge, se continua a guastare il motore SMART, sicuramente su unità SAS, sostituisce logicamente il cluster o il settore con uno che è buono. utilizzando cluster di riserva. questo ripara il danno. Sì, tutte le unità crescono male dal primo giorno alla fine, dalle prime unità IBM a ORA. ma ora facciamo l'autoriparazione, leggi i white paper completi di Seagate. infinito lì, e scopri come funziona un disco. ok?

questo continua fino a quando non si esauriscono i pezzi di ricambio (hdd brain, smart) e quindi SMART urla END OF LIFE. (o anche più presto, come fa HP), diciamo un controller HP P420, lo guarda sempre. Il mio mi ha persino inviato un'e-mail, mostrando i cluster VICINO A FUORI RICAMBIO. A volte i ricambi vanno molto più velocemente, un sicuro segno di sventura presto (10 anni, certo, meno in junky sata.

Chiamo BOGUS e FUD sul bit rot.

La mia ipotesi è che qualcuno PC giocattolo abbia scritto i dati in modo errato, per qualsiasi motivo. non esegue la memoria ECC ?? oops, i server reali hanno RAM ECC. virus infetto. o perdita di energia durante la scrittura (nessun UPS>?)? o ha cattiva memoria. o ESD danneggiato. O alimentatore che fa tonnellate di rumore (cattivo)

Chiamo FUD qui. spiacente,