I'm confused about a few items in this thread: 1. On normal read, if there's a csum mismatch, there should be a path to file and EIO, because Btrfs won't propagate bad data up to user space. I'd expect if there's metadata corruption, there'd be no path to file, and no EIO. The original email does include an inode, but that's ambiguous since each fs tree has its own set of inodes, so we can't always easily infer a file from an inode.
2. Why does ddrescue work around this problem on a mounted file system? It's just reading the file, through the file system, the exact same errors should have happened. 3. My take on this would have been to use btrfs restore and go after the file path if I absolutely needed a copy of this file (no backup), and then copied that back to the file system. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
