Ricerca di file con errori non corretti di BTRFS

17

Ho una domanda riguardante errori irrecuperabili su un file system BTRFS. In particolare, ho eseguito uno Scrub BTRFS di recente dopo aver riscontrato un problema con uno dei miei stick RAM e sembra aver scoperto 4 errori non correggibili. Questo è l'output:

scrub status for <UUID>
    scrub started at Thu Dec 25 15:19:22 2014 and was aborted after 89882 seconds
    total bytes scrubbed: 1.87TiB with 4 errors
    error details: csum=4
    corrected errors: 0, uncorrectable errors: 4, unverified errors: 0

Fortunatamente ho eseguito il backup di tutto in un backup terziario, quindi non sono particolarmente preoccupato di perdere i file (sono ben consapevole dei problemi associati allo stato sperimentale di BTRFS, ho più backup per mantenere i miei dati al sicuro e determinato a continua ad usarlo, quindi per favore no: messaggi "Soluzione; non usare BTRFS").

Vorrei sapere, tuttavia, come determinare quali file sono associati agli errori non correggibili? Voglio trovarli, eliminarli e sostituirli con le loro copie di backup.

Se qualcuno ha informazioni su come farlo, mi piacerebbe avere tue notizie.

Grazie in anticipo.

backup filesystems btrfs

— RedHack
fonte

8

Ho trovato utile il seguente metodo ...

btrfs scrub il volume.

Ti verrà presentato un numero qualsiasi di errori csum come mostrato sopra.
Utilizzando i dettagli dell'errore di esempio : csum = 4 . Usa quel numero nella direttiva di coda della seguente dichiarazione:

dmesg | grep "checksum error at" | tail -4 | cut -d\  -f24- | sed 's/.$//'

È utile reindirizzare questo in un file (ad es. > csums.txt)

Ho provato un certo numero di approcci alla ricerca di inode suggeriti e tutti hanno avuto un successo limitato o limitato.

— marchio
fonte

— niklasfi

3

Sì, il mapping da INODE o Block Number a un nome file può essere difficile. Se sei veramente interessato, puoi provare qualcosa del genere e vedere quali file file copiare ... dopotutto se il file è danneggiato dovrebbe generare un errore durante la copia. In precedenza ho usato questo tipo di tecnica.

 find /mount-point -type f -exec cp {} /dev/null \;

 where mount-point is the ROOT node/mount-point of the affected filesystem

— MDPC
fonte

Eseguendolo ora, si spera che si alzi qualcosa. Grazie per il tuo consiglio, ti aggiornerò sul risultato.

— RedHack,

1

Mi dispiace dire che non sembra funzionare = / ha trovato il primo file che causa l'errore non correggibile, ma poi invia il messaggio: "handle di file non aggiornato" al terminale a meno che non lo concluda. Concesso che ha trovato il file, ma ora non riesco a capire come liberarmene. Devo contattare la mailing list di BTRFS.

— RedHack,

Puoi spostarlo in una directory speciale e quindi escluderlo da un'ulteriore ricerca.

— mdpc,

1

Non si sposta né copia, continua a dirmi che l'handle del file è obsoleto. Non posso nemmeno ls.

— RedHack,

Se si utilizza cp -v, si può anche monitorare lo stato di avanzamento: find / -type f -exec cp -v {} /dev/null \; 2> corrupted-files.txt. Tuttavia, il /proc/kcorefile potrebbe essere enorme (il mio era 128 TB), quindi l'operazione di copia probabilmente si bloccherà. Poiché la /procdirectory contiene file magici speciali, non è necessario verificarli. Escludere la /procdirectory:sudo find / -type f -and -not -path /proc -exec cp -v {} /dev/null \; 2> corrupted-files.txt

— ceremcem,

2

dmesgti fornirà dettagli sui file coinvolti negli errori di checksum non correggibili. I messaggi in genere si presentano così: "BTRFS: errore di checksum in [...] logico su dev [...], settore [...], root [...], inode [...], offset [ ...], lunghezza [...], collegamenti [...] (percorso: [...]) "; l'ultima informazione è il percorso assoluto del file danneggiato.

— arrrr
fonte

1

Sono venuto qui cercando "Errore non correggibile" anche da BTRFS. Il grep sopra non ha funzionato per me; Ho dovuto usare invece:

$ dmesg | sed -n -r 's#.*BTRFS.*i/o error.*path: (.*)\)#\1#p' | sort -u
somepath/somefile.txt

Nota come il percorso è relativo all'inizio del sottovolume - nessuna indicazione di quale sottovolume si trova. Questo per fortuna non è stato un problema per me.

— crusaderky
fonte

Che cosa è somepath/somefile.txt? Sembra che tu lo stia digitando come comando separato - o è l'output del comando che hai digitato? Se si suppone che sia tutta una riga di comando, ti preghiamo di non dividere le righe di comando a scopo di visualizzazione, ma inseriscilo nella risposta come una riga lunga. Ma cos'è? Stai fornendo due input a sort(una pipe e un file)? O è somepath/somefile.txtpensato per essere un file di output? (Non è molto utile specificare i file di output, a meno che non si tratti di file intermedi che si stanno utilizzando di nuovo. Le persone sanno come gestire i risultati; ad esempio, tramite piping.)

— Scott

Questo risponde alla domanda originale? Non so dirlo.

— Dico Reintegrare Monica il

@TwistyImpersonator Beh, è (IMO) chiaramente inteso come un'alternativa alla risposta di Mark , e che ha ottenuto otto voti (ed è un'espansione della risposta di Arrrr ).

— Scott,

1

@Scott la seconda riga era un esempio di output del comando.

— crusaderky,