2007/11/20, Raffaele BELARDI <raffaele.belardi@st.com>:
>
> 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