Depending on the disk, you can possibly get a vendor tool to disable bad
block relocation. This way, if a block can't be read the disk will not
do it's internal magic to remap the block to another part of the disk.
Some vendors also offer a disk copy tool which can skip the unreadable
parts, similar to what ddrescue ends up doing but can be significantly
faster.
John.
Dag Wieers wrote:
> On Wed, 22 Jun 2005, Nikos Zaharioudakis wrote:
>
>
>>try something like this.
>>fdisk -l /dev/hda (no 1,2 etc just the drive)
>>if it gives you back some partition table then you have hope.
>
>
> Even when it fails to return a partition table there is still hope.
>
> I actually had problems, fdisk -l didn't work, partitions couldn't be
> mounted read-only. But after ddrescueing the complete disk I still had
> 99.983% of my disk (about 30MB of the 160GB was lost, most of it on the
> recently formatted and therefor empty partition, only 2.2MB of real data
> was impacted)
>
> Strangely, fdisk -l on the copied disk worked without a problem. According
> to ddrescues output:
>
> Bad region size 32768 at position 4096
> Bad region size 4096 at position 49152
> ...
>
> I verified fdisk's behaviour with strace and apparently it first reads the
> first 512 bytes, but then strangely reads the first 8k. Since that fails,
> I was out of luck.
>
>
>
>>try to mount the drive with ro (read only option we do not need to
>>change anything on it, we just want the data)
>
>
> Don't do this after a reboot, chances are the disk is dying, might go bad
> while using it and the filesystem might not recover from the problems
> anyway. If the system was still running, you might want to copy files off
> the filesystem (since the disk might not come back after a reboot). If you
> rebooted the system, use a rescue CD (knoppix) that has dd_rescue on it
> and use that to copy the complete block-device.
>
> You can also download gnu ddrescue to your knoppix ramdisk, compile it and
> use that. It is more sophisticated and you can first recover the major
> working areas with a big blocksize and later refine the bad areas (when
> the disk might be even less reliable).
>
>
>
>>If this fails for any reason, try to dd the whole disk to another
>>(good one) and then mounting and perhaps fsck might give you your data
>>back.
>
>
> dd will not work if you have bad blocks, it fails on the first bad block.
>
> Also, before running fsck you might want to make a second copy, in case
> the fsck fails. You don't need to copy everything back from the broken
> disk, but instead try to refine copying the bad areas (some reports say
> freezing the disk in the freezer helps ?).
>
> In my case it took 18h to copy the good parts, but refining the bad areas
> takes 4 secs for 1 bad block (512 bytes). So you might not want to do that
> at first or it could take a week (in my case 3 days for 30MB) refining
> every bad area.
>
> -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ --
> [all I want is a warm bed and a kind word and unlimited power]
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
>
>
--
John Newbigin
Computer Systems Officer
Faculty of Information and Communication Technologies
Swinburne University of Technology
Melbourne, Australia
http://www.ict.swin.edu.au/staff/jnewbigin
