Hi Mitch, hi all,

thanks for your hint.

I used btrfs-debug-tree now.
With -e, the output is empty. But without -e I do get a bit output file.
When I search for Filenames that I am missing, I get:

grep Sting big_output_file  |grep Berlin
                 namelen 20 datalen 0 name: Sting_Live_in_Berlin
                 namelen 20 datalen 0 name: Sting_Live_in_Berlin
                 inode ref index 29 namelen 20 name: Sting_Live_in_Berlin

That looks good.
That raises two questions now: Can I restore the file?
And: Can I do that for a whole Path (e.g. ./Video/)

Greetings&Thanks!
Hendrik


Am 15.12.2012 23:24, schrieb Mitch Harder:

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

quoted

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Hendrik Friedel
Auf dem Brink 12
28844 Weyhe
Mobil 0178 1874363