Est-il possible de récupérer explicitement le contenu complet du file avec une sum de contrôle incorrecte sur un système de files btrfs?

Imaginez une situation où un file est devenu corrompu sur un seul périphérique Btrfs. Et dans ce cas, le contenu du file est nécessaire, y compris les bits corrompus.

Comme indiqué dans la page de manuel pour mount:

nodatasum Enable/disable data checksumming for newly created files. 

Ainsi, il ne désactivera pas les vérifications de checksum lors de la lecture des files.

Et comme je suppose que tous les appels système standard impliquant le système de files pour la lecture échoueront à ce file. La lecture de disque brut n'est pas une option en raison de la fragmentation probable.

Lorsque j'essaie de cat tel file, j'obtiens une erreur:

 cat: file: Input/output error 

dmesg rapporte des messages comme ceux-ci:

 [631847.884641] BTRFS warning (device loop0): csum failed ino 257 off 0 csum 1280268577 expected csum 2391276770 

Avoir des informations que la corruption se produit à off 0 , donc c'est 4096 premiers octets de file, en effet, je suis en mesure de récupérer des blocs non corrompus assez facilement:

 dd if=file bs=4K skip=1 

Btw, écrire et append des données à des blocs non corrompus de file corrompu réussit également. Au less quand il n'y a qu'un seul bloc corrompu et ce n'est pas le dernier. Au début, cela m'a surpris, mais je pense que c'est probablement une bonne fonctionnalité, de sorte que les applications qui doivent append des données critiques ne seront pas bloquées sur un file corrompu.

La question est de savoir comment récupérer datatables du bloc corrompu (ou du file corrompu)?

En dernier recours, vous pouvez essayer

 btrfs check --init-csum-tree /tmp/copy_of_the_device.bin

Cette command va changer le système de files et le résultat peut être pire qu'avant, alors exécutez ceci uniquement sur une copy dd ou ddrescue du système de files.