On Jun 25, 2014, at 1:32 PM, Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx> wrote: >> I don't know all states of this file system, and copies you have. Right now the earliest copy is obviously broken, and the latest copy is probably more broken because at the least its csum tree has been blown away meaning there's no checksums to confirm whether any data extracted/copied from the file system is OK. You'd just have to open the file and look at it to see if it behaves as it should, and even then depending on what kind of file it is, corruption may not be obvious immediately. So... catch22. > > I'm not sure I follow you. I have a clean dd image, and I made a fresh > copy of it every time I tried something new, so no copy should be any > more broken than whatever the current recovery operation did to it. e.g. --init-csum blows away checksums, so any file read will show checksum mismatches. And I'm not sure the state of btrfs check --repair but in the recent past it has sometimes made problems worse. So that's what I mean. If you're making new copies each time, then of course the original isn't affected… > (There shouldn't be a distinction between earliest and latest if I > understand what you mean by "copy".) > > I get all those tree errors when it tries to access the "active" > versions of the @ and @home volumes. But by the time it starts > restoring the snapshots I don't see those anymore. So my > interpretation of the output was that the trees rooted at @ and @home > are messed up, but the tree structures for the snapshots are ok. Am I > misunderstanding that output, or are we both equally in the dark about > what it's telling us? I'm definitely in the dark about what it's saying. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
