On Sun, Sep 4, 2016 at 12:51 PM, Hendrik Friedel [off-list ref] wrote:

Hello again,

before overwriting the filesystem, some last questions:

quoted

quoted

 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?

quoted

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?

quoted

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