Welcome, Guest. Please login or register.
Did you miss your activation email?
May 23, 2013, 10:36:02 PM
Home Help Search Login Register
News: Using Internet Explorer 8? Use compatibility mode when posting!

+  DIY DataRecovery.nl Support forum
|-+  Support
| |-+  DiskPatch (Moderators: Tom, Joep)
| | |-+  Cannot read MBR, will not generate a log file
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: 1 [2] Go Down Print
Author Topic: Cannot read MBR, will not generate a log file  (Read 3019 times)
michael_s
member

Posts: 12


« Reply #15 on: May 03, 2010, 07:51:21 PM »

To clarify the issue a bit, here is what I am seeing.

Diskpatch clone runs normally for about 4 to 5 million sectors, then it slows way down (I am assuming it hits a read error). This is to be expected. I wait for it to clear the sectors that are damaged (I have it set to skip the highest amount of sectors after a read error).

I noted the sector where the read error occurs.

I let disk patch run for 2 days slow like this, and it gets an error every 8 reads for the entire 2 days, for over 4000 read errors in those 2 days.

I assume something must be amiss, as I know that the drive, although in bad shape, does not have that much damage. So I stopped the clone and rebooted the system.

I then restarted the clone process from the sector where I saw the initial read error. And to my surprise, disk patch runs fast from that point through all the sectors that it previously had errors on, not a single error in the entire section of the disk that was previously reporting over 4000 read errors.

Disk patch continues for about 4 to 5 million sectors with no errors, then the same thing happens again. I note the sector where the first error is reported and let it run for an hour. Again every eight data reads I get an error for a total of about 60 errors in the hour.

I stop disk patch, reboot and restart the clone at the point of the first reported error, and again not a single read error for 4-5million sectors where there were previously 60 errors.

This behavior is repeatable on my system and I have now gone through this entire process about a dozen times to keep disk patch moving at a reasonable rate.

Why is disk patch reporting errors and then after a reboot not reporting errors over the same stretch of sectors?
Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1160


WWW
« Reply #16 on: May 03, 2010, 09:35:32 PM »

Hello,

The errors we see in earlier logfiles are 'time-outs'. DiskPatch 'instructs' the BIOS to read a sector. The BIOS then issues a command to the disk to read a sector. Disk reports back to the BIOS, the BIOS passes the message to DiskPatch. In this case the BIOS tells 'The disk did not reply back'. That does not mean a sector is bad. That can explain why certain sectors can be read once you restart the clone.

If the source disk and the destination disk are one one cable, try using seperate ones. For testing purposes, disable the disk reset option in DiskPatch and see of improves matters. In DiskPatch set read retries to zero. Each retry or disk reset can take upto minutes depending on the disk brand and revision.
Logged

--
Kind regards,
Joep
michael_s
member

Posts: 12


« Reply #17 on: May 03, 2010, 10:33:12 PM »

Hi,

The disks are on separate interfaces.

The source disk is on its own SATA cable to the motherboard. The destination disk is attached by USB.

The disk reset option has been disabled for the entire clone. Read retries was already set to 0 as well.

My question is why does it always go for approx. 4 million sectors and start doing this again and again? I have now had to reboot 2 more times to continue cloning at normal speeds. Again 4 million sectors, reboot, back to normal.

I am just a bit puzzled by the repeatability of the issue. It points to something that is happening over and over. If I could stop it from happening and finish this clone before next month, I would be extremely happy.



Logged
Tom
Developer and Support Tech
Administrator
member
*****
Posts: 1147


WWW
« Reply #18 on: May 04, 2010, 10:29:16 AM »

It is most likely a problem in the communications between the BIOS and the disk. DiskPatch (as stated) sends requests for disk access and if the BIOS can't provide the sectors things go off the track a bit. I don't see it being a DiskPatch problem or memory problem; the cloning procedure is a relatively simple operation and memory issues in DOS manifest themselves differently. It's more likely to be found in the disk communications and/or how the BIOS handles the disk reads. Which means there isn't much we can do about how this is going.
You can play a little with some settings (in DiskPatch, the disk reset option may improve things, but it may also slow things down even more). And perhaps your BIOS has some disk access options that may change things, though that isn't likely.

There are some notes:

First, USB is not the best way to connect a disk for a cloning operation. If it works, great, but USB is known to cause problems when DOS / low level access is required (in the way that DiskPatch does it for cloning). At the very least it will be slow, but that doesn't seem to be the biggest problem in your case. It's always preferred to have disks connected directly, but like I said, if it works I suppose you can continue.
Second, there's a small chance that a BIOS update may improve things (it wouldn't be the first time) but that is a long shot. However, you may want to check the BIOS revision and see if there is a newer version.
Third, using an entirely different PC may change things. If you have the option to switch to another PC, try that and see if it makes a difference.
Logged

michael_s
member

Posts: 12


« Reply #19 on: May 04, 2010, 04:56:15 PM »

I have another more current machine that I can use, and I will switch everything over to that machine to continue the process so I can get both drives on a SATA connection. Hopefully that will make a difference.
Logged
Pages: 1 [2] Go Up Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!