Localizando arquivos com erros incorrigíveis do BTRFS

17

Tenho uma pergunta sobre erros irrecuperáveis em um sistema de arquivos BTRFS. Especificamente, eu executei um Scrub BTRFS recentemente após encontrar um problema com um dos meus sticks de RAM e parece ter descoberto 4 erros incorrigíveis. Esta é a saída:

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

Felizmente, tenho tudo em backup em um backup terciário, por isso não estou particularmente preocupado com a perda de arquivos (estou ciente dos problemas associados ao status experimental do BTRFS, tenho vários backups para manter meus dados seguros e decidido a continue usando-o, então não: postagens "Solução; não use BTRFS").

Gostaria de saber, no entanto, como determinar quais arquivos estão associados aos erros incorrigíveis? Quero encontrá-los, excluí-los e substituí-los por suas cópias de backup.

Se alguém tiver informações sobre como fazer isso, eu adoraria ouvir você.

Agradeço antecipadamente.

backup filesystems btrfs

— RedHack
fonte

8

Eu achei o seguinte método útil ...

btrfs scrub o volume.

Você verá vários erros de csum, como mostrado acima.
Usando seus detalhes de erro de exemplo : csum = 4 . Use esse número na diretiva final da seguinte instrução:

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

É útil canalizar isso para um arquivo (por exemplo > csums.txt)

Eu tentei várias abordagens de pesquisa de inode sugeridas e todas elas tiveram sucesso limitado, se houver.

— Marca
fonte

— niklasfi

3

Sim, o mapeamento de INODE ou Número do bloco de volta para um nome de arquivo pode ser difícil. Se você está realmente interessado, pode tentar algo como isto e ver quais arquivos de arquivo copiar ... afinal, se o arquivo estiver ruim, deve ocorrer um erro durante a cópia. Eu já usei esse tipo de técnica.

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

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

— mdpc
fonte

Executá-lo agora, espero que isso aconteça. Obrigado pelo seu conselho, vou atualizá-lo quanto ao resultado.

— RedHack

11

Lamento dizer que parece não funcionar = / ele encontrou o primeiro arquivo causando o erro incorrigível, mas depois envia a mensagem: "identificador de arquivo obsoleto" para o terminal, a menos que eu o encerre. Concedido que encontrou o arquivo, mas agora não consigo descobrir como se livrar dele. Vou ter que entrar em contato com a lista de discussão do BTRFS.

— RedHack

Você pode movê-lo para um diretório especial e excluí-lo de uma pesquisa adicional.

— Mdpc

11

Ele não se move ou copia, apenas me diz que o identificador de arquivo está obsoleto. Eu não posso nem mesmo.

— RedHack

Se você usar cp -v, você também pode monitorar o progresso: find / -type f -exec cp -v {} /dev/null \; 2> corrupted-files.txt. No entanto, o /proc/kcorearquivo pode ser enorme (o meu tinha 128 TB), portanto a operação de cópia provavelmente travará. Como o /procdiretório contém arquivos mágicos especiais, não precisamos checá-los. Exclua o /procdiretório:sudo find / -type f -and -not -path /proc -exec cp -v {} /dev/null \; 2> corrupted-files.txt

— ceremcem 12/12/19

2

dmesgfornecerá detalhes sobre os arquivos envolvidos nos erros incorretos da soma de verificação. As mensagens geralmente têm a seguinte aparência: "BTRFS: erro de soma de verificação no [...] lógico no dev [...], setor [...], raiz [...], inode [...], deslocamento [ ...], comprimento [...], links [...] (caminho: [...]) "; a última informação é o caminho absoluto para o arquivo que está corrompido.

— arrrr
fonte

1

Eu vim aqui procurando também o "erro incorrigível" do BTRFS. O grep acima não funcionou para mim; Eu tive que usar:

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

Observe como o caminho é relativo ao início do subvolume - nenhuma indicação de qual subvolume está. Felizmente, isso não foi um problema para mim.

— crusaderky
fonte

O que é somepath/somefile.txt? Parece que você está digitando como um comando separado - ou é a saída do comando digitado? Se tudo deve ser uma linha de comando, não separe as linhas de comando para fins de exibição - basta colocá-lo na resposta como uma linha longa. Mas o que é isso? Você está fornecendo duas entradas para sort(um pipe e um arquivo)? Ou somepath/somefile.txtdeve ser um arquivo de saída? (Não é muito útil para especificar arquivos de saída, a menos que sejam arquivos intermediários que você está usando novamente As pessoas sabem como lidar com os resultados; por exemplo, através de tubulação..)

— Scott

Isso responde à pergunta original? Não sei dizer.

— Eu digo Reinstate Monica

@TwistyImpersonator Bem, é (IMO) claramente destinado a ser uma alternativa à resposta de Mark , e obteve oito votos (e é uma expansão da resposta de arrrr ).

— Scott

11

@Scott a segunda linha foi uma saída de amostra do comando.

— Crusaderky #