On Sat, Dec 15, 2012 at 1:40 PM, Hendrik Friedel <hendrik@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
