2006/2/14, Neil Brown <neilb@xxxxxxx>: > On Tuesday February 14, krekna@xxxxxxxxx wrote: > > Krekna is crying out loud in the empty wilderness.... > > No one there to help me? > > Nope :-) > > > > I did the folowing: > > > > > > dd conv=noerror if=dev/hdd1 of=/mnt/hdb1/Faulty-RAIDDisk.img > > > losetup /dev/loop0 /mnt/hdb1/Faulty-RAIDDisk.img > .. > > > > > > But it did not work out (yet). > > > > > > madm -E /dev/loop0 > > > mdadm: No super block found on /dev/loop0 (Expected magic a92b4efc, > > > got 00000000) > ... > > > > > > - can I restore the superblock from the hdd1 disk (which is still alive) > > > > > If mdadm -E /dev/hdd1 shows a valid superblock, and mdadm -E > /dev/loop0 doesn't, then your 'dd' wasn't very successful. Hi, Actually, /dev/hdd1 partition is 390708801 blocks, the disk itself is a Hitachi 400GB disk. So this is 390708801 blocks of 1024 bytes. This is according to my calculation 400085812224 bytes. The Faulty-RAIDDisk.img is according to my ls -l 400085771264 bytes. So it looks like they are quite the same, and the difference between the two is 40960 bytes. These are 40 blocks, so 36 are missing? The dd actually succeeded, and did finish the job in about one day. The badblocks were found after about the first 7 Gigs. Is there no way like the conv=noerror for mdadm, to just continue? Can I restore the superblock on the .img file somehow? Is it probably save to --zero-superblock all the three disks and that the RAID array will create two new superblocks (Leaving the spare out, because its probably out of date). I can do the dd again, but I think it will do the same thing, because it finished 'succesfully'. The superblock is at the end of the disk I read, about the last 64-128K or something. Krekna > > What is the size of /mnt/hdb1/Faulty-RAIDDisk.img ?? What is the size > of /dev/hdd1? > > BTW, you don't need to edit mdadm.conf to try things out. Just > > mdadm -A /dev/md0 /dev/hdb1 /dev/hdc1 /dev/loop0 > > NeilBrown > - 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
