0

After my system crashed, I get an I/O Error when I try to read a specific file. I run btrfs scrub and found a checksum mismatch affecting this file.

Now I want to test, if at least parts of this file are still intact. How can I force btrfs to read the file anyway?

EDIT: I tried btrfs check --fix-crc as suggested in another thread, but neither does it seem to understand the fix-crc flag, nor can I find it in the man page. Maybe it's deprecated?

I know there's btrfs check --init-csum-tree, but as far as I know it completly recalculates all checksums, which means completly re-reading all hard drive contents.

EDIT 2: I was able to get the file contents that weren't affected with ddrescue. However, I'd also like to access the contents of the bad sector (since the I/O Errors are only generated by btrfs checksum failure, afaik the disk is ok).

The dmesg log only shows csum failed root 5 ino 130384 off 260317184 csum 0x8068db14 expected csum 0x240ab6d1 mirror 1. The given offset is only local to the file, that is unreadable. If I could somehow get the affected partion block, I could easily read the contents using dd.

tommy0010
  • 1

1 Answers1

0

A solution not specific to Btrfs.

The file is seekable and you can read it piece by piece, except in your case one or more pieces will turn out to be unreadable.

GNU ddrescue can do all this work for you. I use it usually to read block devices sector by sector but one can use it with regular files as well.

ddrescue /path/to/affected/file /where/to/save/copy mapfile

In my Kubuntu ddrescue uses 512 bytes as default sector size (-b 512). Since any hardware uses 512 or 4096 and Btrfs usually(?) uses at least 4096 bytes, the default value should be OK to get as much of the file as possible with this method.

Kamil Maciorowski
  • 81,893