From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de ([212.227.17.9]:51072 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751691Ab2LOTk7 (ORCPT ); Sat, 15 Dec 2012 14:40:59 -0500 Message-ID: <50CCD247.3090701@friedels.name> Date: Sat, 15 Dec 2012 20:40:55 +0100 From: Hendrik Friedel MIME-Version: 1.0 To: Mitch Harder CC: linux-btrfs@vger.kernel.org Subject: Re: segmentation-fault in btrfsck (git-version) References: <50BFB3B2.8040405@friedels.name> <50C4E152.2000102@friedels.name> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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. Greetings, Hendrik -- Hendrik Friedel Auf dem Brink 12 28844 Weyhe Mobil 0178 1874363