Imagine uma situação em que um arquivo foi corrompido em um único dispositivo Btrfs. E, neste caso, o conteúdo do arquivo é necessário, pois inclui bits corrompidos.
Como afirmado na man page do mount:
nodatasum
Enable/disable data checksumming for newly created files.
Por isso, não desativa as verificações de soma de verificação ao ler arquivos.
E, como eu acho, todas as chamadas de sistema padrão envolvendo sistema de arquivos para leitura falharão nesse arquivo. A leitura bruta do disco não é uma opção devido à provável fragmentação.
Quando tento cat desse arquivo, recebo um erro:
cat: file: Input/output error
dmesg relata mensagens como estas:
[631847.884641] BTRFS warning (device loop0): csum failed ino 257 off 0 csum 1280268577 expected csum 2391276770
Tendo informações de que a corrupção ocorre em off 0 , então são os primeiros 4096 bytes de arquivo, de fato eu sou capaz de recuperar blocos não corrompidos muito facilmente:
dd if=file bs=4K skip=1
Btw, escrever e anexar dados a blocos não corrompidos de arquivos corrompidos também é bem-sucedido. Pelo menos quando há apenas um bloco corrompido e não é o último. No começo, me surpreendeu, mas acho que provavelmente é um bom recurso, para que os aplicativos que precisam anexar dados críticos não fiquem presos em um arquivo corrompido.
A pergunta é como recuperar dados de um bloco corrompido (ou de um arquivo corrompido inteiro)?
Como último recurso, você pode tentar
btrfs check --init-csum-tree /tmp/copy_of_the_device.bin
Este comando irá mudar o sistema de arquivos e o resultado pode ser pior do que antes, então execute isto apenas em uma cópia dd ou ddrescue do sistema de arquivos.
Tags data-recovery btrfs checksum