[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: botched RAID, now e2fsck or what?



Hi,

Thanks both for replies. Things are moving now, since I started using
e2fsck -n -f -v /dev/md0

However, no combination seems useful. Sometimes I get:
"e2fsck: Bad magic number in super-block while trying to open /dev/md0"
Other times I get:
"Superblock has an invalid journal (inode 8)."
Other times I get:
"e2fsck: Illegal inode number while checking ext3 journal for /dev/md2."
None of these appears in only one permutation, so none is indicative
for the corectness of the permutation.

I also ran dumpe2fs /dev/md2, but I don't know how to make it more
useful than it is now. Right now it finds supernodes in a series of
permutations, so again, it is not of much help.
Question 1: Is there a way to make dumpe2fs or another command
estimate the number of files in what appears to be an ext3 partition?
(I would then go by the permutation which fonds the largest number of
files.)
Question: if I were to struck lucky and find the right combination,
would dumpe2fs give me a very-very long list of superblocks? Do the
superblocks extend far into the partition, or do they always stop
early (thus showing the same number each time my RAID starts with the
right drive)?

Question 3: Is there any other tool that would search for files in the
remains of an ext3 partition, and, this way, validate or invalidate
the permutations I try?

Thanks,
Lucian Sandor


2009/12/9 Eric Sandeen <sandeen redhat com>:
> Lucian Șandor wrote:
>> Hi all,
>>
>> Somehow I managed to mess with a RAID array containing an ext3 partition.
>>
>> Parenthesis, if it matters: I disconnected physically a drive while
>> the array was online. Next thing, I lost the right order of the drives
>> in the array. While trying to re-create it, I overwrote the raid
>> superblocks. Luckily, the array was RAID5 degraded, so whenever I
>> re-created it, it didn't go into sync; thus, everything besides the
>> RAID superblocks is preserved (or so I think).
>>
>> Now, I am trying to re-create the array in the proper order. It takes
>> me countless attempts, through hundreds of permutations. I am doing it
>> programatically, but I don't think I have the right tool.
>> Now, after creating the array and mounting it with
>> mount -t ext3 -n -r /dev/md2 /media/olddepot
>> I issue an:
>> e2fsck -n -f /media/olddepot
>> However, I cycled through all the permutations without apparent
>> success. I.e., in all combinations it just refused to check it, saying
>> something about "short read" and, of course, about invalid file
>> systems.
>
> As Christian pointed out, use the device not the mountpoint for the fsck arg:
>
> [tmp]$ mkdir dir
> [tmp]$ e2fsck -fn dir/
> e2fsck 1.41.4 (27-Jan-2009)
> e2fsck: Attempt to read block from filesystem resulted in short read while trying to open dir/
> Could this be a zero-length partition?
>
>
>  :)
>
> -Eric
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]