Re: segmentation-fault in btrfsck (git-version)

[Hendrik Friedel <hendrik@friedels.name>]

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 <hendrik@friedels.name> wrote:
>> Hello Mitch, hello all,
>>
>>
>>> 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.
>>
>>
>>> 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.
>>
>>
>>> 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.
>>
>>
>>> 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