Sign in to follow this  
Guest russofris

Gheto DFT?

Recommended Posts

Guest russofris

Hi there,

I'm working on my neighbor's toshiba laptop. Prior to beginning the work, I imaged his raw device to a network storage device via:

ddrescue -n /dev/sda /mnt/backup/bosbBackup.img /mnt/backup/bobsBackup.ddrescue.log

There were 138 read errors which I managed to trim down to 2MB worth of overall data loss. Not too shabby. I then tried the HGST DFT utility, so that I could re-zero the drive, have the bad sectors reallocate, and continue along my happy way. Unfortunately, DFT was unable to detect the hitachi SATA HDD on the laptop's Intel (mobile 4) controller.

It then occurred to me that all that DFT does to reallocate sectors is write to bad sectors a couple dozen times, which makes the HDD take notice, and reallocate the sectors via HDD firmware. So I though to myself... can't I just do that myself? I have ddrescue, I have the sectors that I want reallocated in a logfile. Can't I simply do something like:

cp /mnt/backup/bobsBackup.log /mnt/backup/bobsBackup.lst
ddrescue -r1 /dev/zero /dev/sda /mnt/backup/bobsBackup.lst

Basically, set /dev/zero as a source, the HDD as a dest, and provide the a copy old log as an input file? I could then loop it (while true; do) and I'd basically be writing zeros to the bad sectors over and over again to coerce reallocation. Unfortunately, the above doesn't actuall work as I had intended... Does anyone have a simpler way of accomplishing the exact same thing? Otherwise I'm stuck zero'ing the entire drive a few dozen times, or dead-rekoning the position of the clusters and doing them individually.

Other note: The pseudo code above is just conceptual and does not actually work. I'm trying to specify direct mode output and a couple other tricks. Nothing works yet and I have about 1hr invested. If I find something, I'll post it.

Frank

Edited by russofris

Share this post


Link to post
Share on other sites
Guest russofris

The pseudo code above is just conceptual and does not actually work. I'm trying to specify direct mode output and a couple other tricks. Nothing works yet and I have about 1hr invested. If I find something, I'll post it.

Frank

The following appears to work:

cp /mnt/backup/bobsBackup.log /mnt/backup/bobsBackup.lst
ddrescue -D --force --max-size 159G /dev/zero /dev/sda /mnt/backup/bobsBackup.lst
if you hit a write error:
ddrescue -D -R --force --max-size 159G /dev/zero /dev/sda /mnt/backup/bobsBackup.lst

Best case is that this completes and the disk is good. Worst case is that the disk suffers from write errors in both directions, resulting in >2 remaining bad spots in bobsBackup.lst .

Still figuring out a way to automagically doing all of this. In my case, I went from 138 disk errors to 22 disk errors, at least two of which are really bad.

Edited by russofris

Share this post


Link to post
Share on other sites
Guest russofris

Just to put some closure on this, here's my 10 step data-recovery Gheto DFT.

When you have an unsupported drive with no DFT tool, or cannot get the DFT tool to access the drive on the controller:

1: Backup the raw drive to a raw image file. Make the first run quick. It's probably going to take all night

mkdir /mnt/backup
mount //somecomputer/someshare /mnt/backup
ddrescue -n /dev/sda /mnt/backup/bosbBackup.img /mnt/backup/bobsBackup.ddrescue.log

2: Copy off the log file. It contains a full list of problematic sectors. We'll need this later

cp  /mnt/backup/bobsBackup.ddrescue.log /mnt/backup/bobsBackup.ddrescue.sav

3: Attempt to recover the remaining data. ddrescue will trim down the original list of bad sectors and will give you an idea of just how much you have lost.

ddrescue -d -r3 /dev/sda /mnt/backup/bosbBackup.img /mnt/backup/bobsBackup.ddrescue.log

Go to bed, let this run all night. If the data is important, but you're not going to ship it off for recovery, let it run till completion. This might take a couple days.

4: Evaluate the backup:

file /mnt/backup/bosbBackup.img

This should return something like:

bosbBackup.img: x86 boot sector; partition 1: ID=0x27, starthead 32, startsector 2048, 3072000 sectors; partition 2: ID=0x7, active, starthead 89, startsector 3074048, 294373376 sectors; partition 3: ID=0x17, starthead 254, startsector 297447424, 15132672 sectors, code offset 0xc0, OEM-ID "      м", Bytes/sector 190, sectors/cluster 124, reserved sectors 191, FATs 6, root entries 185, sectors 64514 (volumes <=32 MB) , Media descriptor 0xf3, sectors/FAT 20644, heads 6, hidden sectors 309755, sectors 2147991229 (volumes > 32 MB) , physical drive 0x7e, dos < 4.0 BootSector (0x0)

5: Examine the partition table

fdisk -l bosbBackup.img

Disk bosbBackup.img: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x85a142d8

     Device Boot      Start         End      Blocks   Id  System
jrescue.img1            2048     3074047     1536000   27  Hidden NTFS WinRE
jrescue.img2   *     3074048   297447423   147186688    7  HPFS/NTFS/exFAT
jrescue.img3       297447424   312580095     7566336   17  Hidden HPFS/NTFS

6: Let's try to mount the important partition and see if the data is there:

The important partition (in this case) starts on sector 3074048. There's 512 bytes per sector. 512(bytes) * 3074048(start sector of the partition) gives us 1573912576 (offset in bytes)

mkdir /mnt/raw
mount -o ro,loop,offset=1573912576 bosbBackup.img /mnt/raw/
cd /mnt/raw
ls
autoexec.bat  config.sys              MSOCache       $RECYCLE.BIN
Boot          DOCS                    pagefile.sys   System Volume Information
bootmgr       Documents and Settings  ProgramData    Users
BOOTSECT.BAK  hiberfil.sys            Program Files  Windows

(poke around a bit, or open in a gui file manager) We're in read-only mode, so you cannot hurt the image. Copy the image if you need to run chkdsk or some other utility. Do not directly mess with this raw file. Always make a copy and work on the copy.

7: Now let's start repairing the drive. We'll write zeros to the bad spots, and try to force the drive firmware to reallocate the bad blocks. Since we saved the original list of bad blocks in step-2, we can simply use that same list. We're going to select /dev/zero as the source though, and the physical disk (/dev/sda) as the destination. The objective is to write from the source to the dest on the bad blocks (write zeros to the disk over top of the bad sectors). The "max-size" directive must be smaller than the size of the physical disk.

cp /mnt/backup/bobsBackup.ddrescue.sav /mnt/backup/bobsBackup.ddrescue.lst
ddrescue -D --force --max-size 159G /dev/zero /dev/sda /mnt/backup/bobsBackup.ddrescue.lst

if you hit a write error, reverse the direction:

ddrescue -D -R --force --max-size 159G /dev/zero /dev/sda /mnt/backup/bobsBackup.ddrescue.lst

Repeat the above until the errors drop down to (hopefully) zero.

8: Re-zero the entire drive (Just for good measure)

ddrescue -D --force /dev/zero /dev/sda

9: Test the drive

ddrescue /dev/sda /dev/null /mnt/backup/bobsRemainingErrors.log

Repeat 7 and 8 if needed. If you continue to receive write errors, the drive is "really" bad.

10: Restore the image to the drive

dd if=/mnt/backup/bosbBackup.img of=/dev/sda bs=1M

Supplemental: If the HDD cannot be completely repaired, and the damage is located in a single area of the HDD, and the drive cannot be RMA'd, you can always resize/move the partitions in the image file so that the bad sectors are in unpartitioned/unused space and will remain untouched during the course of normal operation. This is "beyond ghetto" though, and the forum language filter prevents me from disclosing the proper nomenclature for this type of fix.

Frank

Edited by russofris

Share this post


Link to post
Share on other sites

I saw this last night and delighted to see this afternoon that you were able to come up with this. I think my friend came up with something similar when he was using this old 40GB Toshiba PATA drive that had thousands of bad sectors grouped together. He wasnt able to remap all of them, but he was able to position the partition in a spot to still use the ghetto-rigged notebook without buying another drive.

Share this post


Link to post
Share on other sites
Guest russofris

I saw this last night and delighted to see this afternoon that you were able to come up with this. I think my friend came up with something similar when he was using this old 40GB Toshiba PATA drive that had thousands of bad sectors grouped together. He wasnt able to remap all of them, but he was able to position the partition in a spot to still use the ghetto-rigged notebook without buying another drive.

Yeah, if all of the bad sectors are local to a single spot on the disk, you can partition around the badness. That's exactly what I had to do for the laptop I just fixed. 160GB disk, 2 unwritable sectors side by side. I placed a 1GB hidden partition on the spot with an ominous looking "Type" ID, and dropped the good partition(s) around it. It's now a 159GB disk.

The main question I have through all of this is, is there any way to manually re-map a sector? If it is simply unreadable, you can write zeros to it and the HDD firmware will remap it. If the sector is unwritable, I'm screwed. I need to find a way to coax a drive into remapping an unwritable/bad sector. I honestly don't know enough about the tech anymore to write something, which is sad.

Frank

Share this post


Link to post
Share on other sites
Guest russofris

After some research, I have not been able to find a method for adding a sector to the G-list manually. I might (given the proper motivation) spring for something like a PC-3000.

If anyone has other ideas on how to coax a drive into remapping a sector that is getting an unrecoverable write error to a particular LBA sector, I'm all ears.

Edited by russofris

Share this post


Link to post
Share on other sites

Outside of using something like spinrite on the drive to force hundreds of attempts, each drive uses their own unique way of handling bad sectors. Heck I still have some in the pending category on this 3TB HD that has been sitting in my NAS with over 5000 hours on it without any luck.

Share this post


Link to post
Share on other sites

Some years ago I was using an IBM Deathstar as a download drive. Upgraded firmware and all, it was still collecting bad sectors every now and then. But I didn't have another drive for this use, and it seemed acceptable to get occasionally some bad sectors and have to redownload (usually just partially).

But forcing a remap was awkward. I don't remember exactly, but it may have involved copying the partially bad file someplace else, deleting it, filling the partition with something, deleting the filler, copying the file back, and redownloading the bad parts.

At some point I thought I'd try to simplify the procedure, assuming all it takes to force a remap is to rewrite once each sector that's flagged bad or potentially bad. I made a utility that did sector-sized unbuffered reads on a file you told it, and for any sector that'd fail or take too long to read (maybe as little as 100-200ms), it'd rewrite it. I tried it a few times, but for some reason it didn't work. I even asked IBM about the remapping procedure but ultimately they didn't give me much info.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this