On Sun, Sep 4, 2016 at 12:51 PM, Hendrik Friedel <hendrik@xxxxxxxxxxxxx> wrote: > Hello again, > > before overwriting the filesystem, some last questions: > >>> Maybe >>> take advantage of the fact it does read only and recreate it. You >>> could take a btrfs-image and btrfs-debug-tree first, >> >> And what do I do with it? >> >>> because there's >>> some bug somewhere: somehow it became inconsistent, and can't be fixed >>> at mount time or even with btrfs check. >> >> Ok, so is there any way to help you finding this bug? > > Anything, I can do here? > >> Coming back to my objectives: >> -Understand the reason behind the issue and prevent it in future >> Finding the but would help on the above >> >> -If not possible to repair the filesystem: >> -understand if the data that I read from the drive is valid or >> corrupted >> Can you answer this? >> >> As mentioned: I do have a backup, a month old. The data does not change so >> regularly, so most should be ok. >> Now I have two sources of data: >> the backup and the current degraded filesystem. >> If data differs, which one do I take? Is it safe to use the more recent >> one from the degraded filesystem? >> > And can you help me on these points? > > FYI, I did a > btrfsck --init-csum-tree /dev/sdd > btrfs rescue zero-log btrfs-zero-log > btrfsck /dev/sdd Curious that this is fixing a parenttransid problem...not sure why. Only a developer working on btrfsck could answer this. They'd need the btrfs-image before these things were done and see what's wrong with the file system that causes check to fail. Changing anything changes the evidence of what was wrong. > > now. The last command is still running. It seems to be working; Is there a > way to be sure, that the data is all ok again? Not by Brfs. The problem now is that by init-csum-tree it recomputed the csums for everything. If there were any files corrupt, they now have csums based on that corruption, so they will read as OK by Btrfs. That's the problem with init-csum-tree. So now you need a different way to confirm/deny if they files are really good or not. -- 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
