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
--
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
