Am 21.02.2013 19:00, schrieb Phil Turmel:
On 02/21/2013 12:47 PM, Stone wrote:
Am 21.02.2013 18:36, schrieb Phil Turmel:
But it does give you the locations of the backup superblocks. Use these
numbers, starting with 32768, as "xxxx" in:
fsck.ext4 -n -b xxxx /dev
Once you give it a superblock that hasn't been corrupted, it should be
able to check the rest of the filesystem. There will be damage near the
beginning, and probably more damage where you had to put zeros.
If it looks like that, do it again without "-n" to actually fix it.
Phil
ok. i think i dont understand you not complete.
i restore now the superblock with --> fsck.ext4 -bv 4096000
/dev/mapper/md2_nas
No! You must keep using "-n" until you have seen a mostly-clean report!
We don't know yet that the chunk size is right.
Leaving off "-n" will simultaneously fix the superblock (and all other
backup copies) and continue to fix the rest of the filesystem. You
mustn't do that with a wrong chunk size--it will damage much more.
ok
when this is done i make full filesystemcheck --> fsck.ext4 /dev/md2_nas
and answer the quest questions.
right?
No.
Just do the "fsck -n -b xxxx" combinations until you find a good
superblock. That report will also show if there are many other errors.
Expect scattered damage in the region < 384MB due to the wrong data
offset. After that, there should only be errors where the new zeros
are, and maybe a few scattered errors from the original crash. If there
many more errors, you have the wrong chunk size.
Phil
ok i have checked all superblocks but i get always the same message.
here one sample:
fsck.ext4 -n -b 644972544 /dev/mapper/md2_nas
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/mapper/md2_nas
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
