On 2017-06-07 17:58, Chris Murphy wrote: > 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.
Usually the number of fs-trees is a lot smaller than the number of files. So even if the fs-root is not displayed, it could be easily guessed. Anyway I understood that the file was found doing "cp -r / /dev/null" (which means try all the files until you find a problem) > > 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. Which problem are you discussing ? Finding the path or getting the data ? Anyway ddrescue is not able to get the data with a wrong checksum. When the data is not good, it is skipped leaving an hole in the destination file. > > 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. It might be useful to have a command to handle these situations: read all the good data, read even the wrong data logging the range were the checksum is incorrect. The fact that you have problem in few bytes, doesn't mean that all the 4k sector has to be discarded. > > > Chris Murphy > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
