2007/11/20, Raffaele BELARDI <[EMAIL PROTECTED]>: > > Duncan wrote: > > If you have a spare drive of the same size or larger, you can try dd, or > > probably better yet, merge dd-rescue and try it. They copy a file or > > part of one, in this case an entire block device, from one location to > > another, "raw". What you want to do is copy the entire bad device, > /dev/ > > sdc above, to the new device. Then you have a copy to play around with > > without worrying about making the bad device worse before you get > > whatever you were trying to get off of it, off. > > > Duncan, > > thanks for the ddrescue explanation, I will surely give it a try. > > Yesterday evening I got a new drive double the size of the damaged one, > created a 250Gb partition on it and tried: > # dd if=/dev/hdb of=/mnt/disk_500/sdb.img > > It stopped after few kb due to read errors. So I modified to > dd conv=noerror if=/dev/hdb of=/mnt/disk_500/sdb.img > > and after some time I got a 250Gb sdb.img on the new drive. > Then started the fun (it was already past midnight). When I created the > new partition I noted down the superblock backup locations. > Unfortunately, every: > # e2fsck -b xxx -B 4096 /mnt/disk_500/sdb.img > > returned 'bad superblock'. After googling for some utility to scan disc > for superblocks, I ended up with testdisk (it's ~amd64). To my > understanding this works on real HW only, so I had to reconnect the > damaged HD and let it do its job. testdisk found the superblocks, but > according to it they were at the exact locations I had already noted, so > no help. I also tried to let it search for partitions because I read it > has an option to parse the directory. It worked, it let me see the list > of lost files, but that's all, it has no option to recover. But at least > it told me there is some good superblock somewhere. > > Finally I went back to the sdg.img and used "od | less" to look at what > was present at the superblock location. What I saw was, I believe, a > part of the superblock (an almost regular patter of numbers, increasing, > which could be a list of blocks? I need to study ext2) but the point is > that this pattern began well before the 'theoretical address' of the > superblock. > > So my hypothesis is that the bad blocks or sectors at the beginning of > the partition were not copied, or only partly copied, by dd, and due to > this the superblocks are all shifted down. Although I don't like to > access again the hw, maybe I should try: > # dd conv=noerror,sync bs=4096 if=/dev/hdb of=/mnt/disk_500/sdb.img > > to get an aligned image. Problem is I don't know what bs= should be. > Block size, so 4k?
this should tell you what the block size is: df /dev/sdc -- dott. ing. beso
