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
  • 3
  • 1
    Possible duplicate of [How to recover this btrfs error?](https://superuser.com/questions/763603/how-to-recover-this-btrfs-error) – harrymc Feb 14 '19 at 21:25

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
  • 69,815
  • 22
  • 136
  • 202
  • They said that the disk was fine and that it was a problem at the filesystem (not block) layer. That being said it would probably be a good idea for them to make an image/clone/copy of the disk somewhere before they try to fix anything. – ATLief Nov 06 '21 at 19:35
  • @ATLief If the disk is fine then trying to *read* a file from it will not break anything. My answer is not an attempt to fix the block device or filesystem. It is an attempt to read as much of the regular file as possible. Many times I have used `ddrescue` to (partially) read regular files from filesystems that were not totally healthy; including cases when Btrfs checksum doesn't match. Note my answer *precedes* [revision 3](https://superuser.com/posts/1405844/revisions) ("EDIT 2") and `ddrescue` worked for the OP exactly to the extent I predicted. The OP actually did benefit from my answer. – Kamil Maciorowski Nov 06 '21 at 19:53
  • What do I use for mapfile if I don't have one, or where do I get the mapfile from? – Alex Ixeras Aug 27 '23 at 10:33
  • 1
    @AlexIxeras `ddrescue` creates a mapfile (unless the mapfile is already there e.g. from previous run(s) of `ddrescue`). I understand you're asking in context of [this other question](https://superuser.com/q/1800564/432690). If you address my comment *there* and tell me e.g. that you read files from CDs and you get read errors (when trying to `cp` or `cat`), then I may be able to guide you specifically. – Kamil Maciorowski Aug 27 '23 at 18:00