D: MDADM mismatch_cnt> 0. Qualche modo per identificare quali blocchi sono in disaccordo?

Va bene. Dopo uno scrub di routine, il mio MDADM RAID5 riporta mismatch_cnt = 16. A quanto ho capito, ciò significa che, mentre nessun dispositivo ha segnalato un errore di lettura, ci sono 16 blocchi per i quali i dati e la parità non concordano.

Domanda n. 1: è possibile ottenere un elenco di questi blocchi?

Domanda n. 2: supponendo che il numero 1 sia possibile, dato che il filesystem sottostante è EXT4, c'è un modo per identificare quali file sono associati a questi blocchi?

Ho dei backup nearline e, in un mondo ideale, potrei semplicemente diffondere l'array live contro i dati di backup per individuare eventuali file che sono stati danneggiati silenziosamente. Ma la realtà sta ricordando che 6 TB di dati di backup sarebbero proibitivi e dispendiosi in termini di tempo. Sapere dove cercare e cosa recuperare semplificherebbe notevolmente le cose.

(Dovrei notare che eseguo solo lo scrub RAID con l'opzione 'check'. L'esecuzione dello scrub con l'opzione 'ripara' sembra terribilmente pericolosa perché MDADM sa solo che i dati o la parità sono sbagliati ma non sa quale. Quindi sembra che il 50% delle probabilità che MDADM indovini e ricostruisca dati errati, quindi desidero sapere quali file sono potenzialmente interessati in modo da poterli ripristinare dal backup, se necessario)

Qualche suggerimento molto apprezzato!

linux mdadm

— arcasinky
fonte

check dmesgo / var / log / syslog?

— psusi,

Ciao. Per quanto ne so, gli unici messaggi registrati su syslog dallo scrubber erano i messaggi di avvio e arresto. Non sono stati registrati messaggi relativi a disallineamenti.

— arcasinky,

Vedi icheck+ ncheckin debugfsper identificare i file in base all'offset del settore.

— sch

Ho provato ad aggiungere la registrazione per il numero di settore. Ora sto cercando di capire cosa fare dopo: unix.stackexchange.com/questions/266432/…

— Peter Cordes,

So che nulla dice che i dischi sono danneggiati, ma controllali. Utilizzare il pacchetto smartmontools per eseguire questa operazione per ciascun disco (come in smartctl -a /dev/sdae così via) oppure utilizzare qualsiasi altro metodo sia necessario eseguire un breve test SMART su ciascun disco e stampare un rapporto completo. È molto probabile che uno di loro stia morendo e ci vuole una grande quantità di malvagità per innescare un allarme generale di salute SMART.

— Spooler

Spiacenti, 'controllo' effettivamente scrivere di nuovo alla matrice quando incontra un errore - vedere https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file /usr/share/doc/mdadm/README.checkarray

'check' è un'operazione di sola lettura, anche se i log del kernel potrebbero suggerire diversamente (es. / proc / mdstat e diversi messaggi del kernel menzioneranno "resync"). Vedi anche la domanda 21 delle FAQ.

Se, tuttavia, durante la lettura, si verifica un errore di lettura, il controllo attiverà la normale risposta a errori di lettura che è quello di generare i dati "corretti" e provare a scriverli - quindi è possibile che un "controllo" attiverà un Scrivi. Tuttavia, in assenza di errori di lettura, è di sola lettura.

... quindi potrebbe essere già troppo tardi per raccogliere i dati che stai cercando, scusa.

A lungo termine, vale la pena notare che RAID5 (e 6 e 1) non hanno protezione contro il bit-rot, che è probabilmente la situazione che hai riscontrato. Quando i dati in un disco vanno a male, non hanno modo di determinare quale dei dati è buono o cattivo. Suggerirei di pianificare la migrazione a un filesystem che esegue il checksum di ogni disco come btrfs o zfs.

(RAID-5 in realtà non dovrebbe essere usato in nuove distribuzioni - e davvero non dovrebbe davvero avere una capacità di dischi grezzi superiore a 2 TB ciascuno - vedi http://www.zdnet.com/article/why-raid-5- smette di funzionare nel 2009 / )

— Andrew W.
fonte