On Sat, Dec 15, 2012 at 1:40 PM, Hendrik Friedel [off-list ref] wrote:

Hello Mitch, hello all,

quoted

Since btrfs has significant improvements and fixes in each kernel

release, and since very few of these changes are backported, it is
recommended to use the latest kernels available.

Ok, it's 3.7 now.

quoted

The "root ### inode ##### errors 400" are an indication that there is
an inconsistency in the inode size.  There was a patch included in the
3.1 or 3.2 kernel to address this issue

(http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=f70a9a6b94af86fca069a7552ab672c31b457786).
  But I don't believe this patch fixed existing occurrences of this
error.

Apparently not. It's still there.

quoted

At this point, the quickest solution for you may be to rebuild and
reformat this RAID assembly, and restore this data from backups.

Yepp, I did that. But in fact, some data is missing. It is not essential,
but nice to have.

quoted

If you don't have a backup of this data, and since your array seems to
be working pretty well in a degraded state, this would be a really
good time to look at a strategy of getting a backup of this data
before doing many more attempts at rescue.

Done. It's all save on another ext4 drive.

So, let's play ;-)
Could you please help me trying to restore the missing Data?

What I tried sofar was:
./btrfs-restore /dev/sdc1 /mnt/restore/

It worked, in a way that it restored what I already had.
What's odd aswell is, that btrfs scrub did run through without errors.
So, the missing data could have been (accidentally) deleted by me. But I
don't think... nevertheless I cannot exclude.

What I know is the (original) Path of the Data.

You could try btrfs-debug-tree, and search for any traces of your
file.  However, be ready to sift through a massive amount of output.