Welcome, Guest. Please login or register.
Did you miss your activation email?
June 20, 2019, 07:33:40 AM
Home Help Search Login Register
News:

+  DIY DataRecovery.nl Support forum
|-+  Support
| |-+  DiskPatch (Moderators: Tom, Joep)
| | |-+  Maximum read errors <32> reach at ... when creating support log
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: 1 [2] 3 Go Down Print
Author Topic: Maximum read errors <32> reach at ... when creating support log  (Read 33048 times)
J
member

Posts: 20


« Reply #15 on: March 01, 2010, 03:33:51 PM »

Oh. Didn't realize that. After which I should run the same repair? Pre vista or post vista?
Logged
Tom
Developer and Support Tech
Administrator
member
*****
Posts: 1476


WWW
« Reply #16 on: March 01, 2010, 03:35:19 PM »

You ran a repair already, you said. We just want to see a fresh support analysis log, of the current situation.

Quote
Is this just a simple matter of changing the partition to NTFS?
No.

About cloning: If pass 1 completed normally, it's possible to re-start pass 2. If you'd be willing to try another time you could try setting readretries to 0 and disabling disk reset (check the options screen) and run a pass 2.
Logged

Tom
Developer and Support Tech
Administrator
member
*****
Posts: 1476


WWW
« Reply #17 on: March 01, 2010, 04:12:28 PM »

To be honest, I'm a bit lost here. After the clone several repairs and undos have been performed and it's pretty tough to figure out now what the state of the disk is. If possible undo everything and post a support analysis log of the original clone, or (even better), restart the clone with the suggestions made earlier (readretries on 0 and disable disk reset) and post a fresh analysis lof of the clone after it has been completed.
Logged

J
member

Posts: 20


« Reply #18 on: March 01, 2010, 04:29:19 PM »

Let me explain the undos.

When I tried to do the repair the 1st time, I selected the vista megabyte interpretation method. When the partition tables were rebuilt, I tried to access the partition in Windows but it was not recognised.

So I undid the repair and tried again using the pre-vista cylinder method. This time Windows' disk management recognised that label (EXT HDD) of the partition. But it was intepreted as RAW.

This is what's happening so far.

Alright! The support analysis log of the clone that you requested earlier -

.....Heads per Track (dec): 255
......Hidden Sectors (dec): 63
..............Unused (hex): 00000000
.............Unknown (hex): 00800080
.......Total Sectors (dec): 1250242496
........MFT Location (dec): 3
.MFT Mirror Location (dec): 49
....Clusters per FRS (dec): 246
.Clusters/Indx Block (dec): 1
...........Volume ID (hex): 35A10E602D06E1D2
........Volume Label (txt): EXT HDD
............Checksum (hex): 00000000
....Sector Signature (hex): AA55
129/001:33/VEC> BS and BBS equal
129/001:33/VEC> Verify EPBR Chain completed
129/001:34/USD> Select disk completed
129/001:37/SCN> DiskScan requested, ScanType is 3
129/001:37/SCN> from 0 (0 0 1) to 1953525167 (121601 80 63), 1953525168 sectors
129/001:37/SCN> Starting QuickScan (pre-vista) at 63 (0 1 1)
129/001:37/CDC> No DataCollection entries, CleanDatacollection aborted
129/001:37/MPL> No DataCollection entries, MakePartList aborted
129/001:37/SCN> Next QuickScan location at 0 (0 0 1)
129/001:37/SCN> QuickScan finished
129/001:37/SCN> Starting SmartScan (pre-vista) at 0 (0 0 1) (JMP=16065, RNG=63)
129/070:54/SCN> SmartScan finished
129/070:54/SCN> DiskScan completed
129/070:54/SCN> ReadErrors for disk 1 (129): 0
129/070:55/LOG> DataCollection items found: 5 / 0
### DATACOLLECTION.ARRAY, FULL ###
SEQ_|___D_|________LOC_|____TYPE_|__COM_|______START_|_____LENGTH_|__PL_|_F
001 | 129 | .........0 | ....EXT | PTE1 | .....16065 | 1250242560 | PRI | .
002 | 129 | .....16065 | ...NTFS | PTE1 | .....16128 | 1250242497 | LOG | .
003 | 129 | .....16128 | ...NTFS | ..BS | .....16128 | 1250242497 | LOG | .
004 | 129 | 1250258624 | ...NTFS | .BBS | .....16128 | 1250242497 | LOG | .
005 | 129 | 1953520064 | ...NTFS | .BBS | ........63 | 1953520002 | PRI | .
129/070:55/LOG> DataCollection items found: 5 / 0
### DATACOLLECTION.ARRAY, CLEANED ###
SEQ_|___D_|________LOC_|____TYPE_|__COM_|______START_|_____LENGTH_|__PL
001 | 129 | .........0 | ....EXT | PTE1 | .....16065 | 1250242560 | PRI
002 | 129 | .....16065 | ...NTFS | PTE1 | .....16128 | 1250242497 | LOG
003 | 129 | .....16128 | ...NTFS | ..BS | .....16128 | 1250242497 | LOG
004 | 129 | 1250258624 | ...NTFS | .BBS | .....16128 | 1250242497 | LOG
005 | 129 | 1953520064 | ...NTFS | .BBS | ........63 | 1953520002 | PRI
129/070:55/LOG> PartList items created: 2
### PARTLIST.ARRAY ###
SEQ_|____TYPE_|_PTE_|__BS_|_BBS_|F8FF_|___S_|___L_|__PL_|_C_|___R
001 | ...NTFS | ... | ... | ..5 | ..0 | ..5 | ..5 | ..5 | 1 | ..B
002 | ...NTFS | ..2 | ..3 | ..4 | ..0 | ..2 | ..2 | ..2 | 3 | ..A
### PARTLIST.ARRAY.INTERPRETED ###
SEQ_|____TYPE_|______START_|_____LENGTH_|________END_|__PL_|___R_|___A
001 | ...NTFS | ........63 | 1953520002 | 1953520064 | PRI | ..B | ..X
002 | ...NTFS | .....16128 | 1250242497 | 1250258624 | LOG | ..A | ..X
129/070:55/SST> SaveState requested for disk 1 (129)
129/070:55/WAS> AdmiSectors in use : 0+ 1+ 2+
129/070:56/SST> SaveState completed for disk 1 (129)
129/070:56/EXE> Analysis complete
129/070:58/LOG> RunTime: 070:58
129/070:58/LOG> ### CLOSE LOG ###

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


WWW
« Reply #19 on: March 01, 2010, 08:40:53 PM »

### PARTLIST.ARRAY.INTERPRETED ###
SEQ_|____TYPE_|______START_|_____LENGTH_|________END_|__PL_|___R_|___A
001 | ...NTFS | ........63 | 1953520002 | 1953520064 | PRI | ..B | ..X
002 | ...NTFS | .....16128 | 1250242497 | 1250258624 | LOG | ..A | ..X


As you can see 2 volumes are found, and they overlap. If you had not already, try this:
select the first one, perform the repair for that volume, test the result. If that doesn't work: select the second, perform the repair, test the result.

If both these tests don't yield any good results, you may assume that the clone was incomplete (because of skipped areas or areas that could not be read). If that's the case the only thing remaining is copying the files from the clone by using file recovery (like our iRecover).

Or:

You could try a new pass 2 as suggested earlier:
"About cloning: If pass 1 completed normally, it's possible to re-start pass 2. If you'd be willing to try another time you could try setting readretries to 0 and disabling disk reset (check the options screen) and run a pass 2."
If you need to know why this is potentially interesting, read the clone section of the manual; the 2 pass clone system is explained there in detail.
Logged

J
member

Posts: 20


« Reply #20 on: March 02, 2010, 03:08:25 AM »

Thanks for analysing the log.

When I saw that the second volume was being recognised correctly as a logical NTFS volume and had an A rating, I was quite happy. It seems that all the parameters are being read right. I don't quite understand why Windows keeps reading it as RAW in spite of all the possibilities of repairs I've tried with DP. Cylinder aligned, megabyte aligned...

I'll try the repair on the first volume and let you know how it turns out.

If both these tests don't yield any good results, you may assume that the clone was incomplete

Correct me if I'm wrong, I'm just making a layman's intepretation here. That I only managed a 1 pass clone means that the image of the volume has some "holes" throughout it. And when the partition is recovered, files that occupy such "holes" will have some corruption. How does this affect the ability of the partition to be mounted into Windows as a whole, notwithstanding the individual files corruption?
Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1476



WWW
« Reply #21 on: March 02, 2010, 08:17:35 AM »

Hello,

Quote
Correct me if I'm wrong, I'm just making a layman's intepretation here. That I only managed a 1 pass clone means that the image of the volume has some "holes" throughout it. And when the partition is recovered, files that occupy such "holes" will have some corruption. How does this affect the ability of the partition to be mounted into Windows as a whole, notwithstanding the individual files corruption?

You're absolutely correct. Depending on where those holes are it sometimes is possible that the copied volumes can be mounted. If Windows displays the partition as RAW then critical file system structures are corrupt or haven't been copied.

Pass 1 means that for each sector that can't be read DiskPatch skips 1024 sectors and for file system structures those are pretty big holes. Because of that a second clone attempt with modified settings for pass 2 was suggested. During pass 2 Diskpatch will retry those skipped holes. With default settings DiskPatch will retry each skipped sector 32 times. Each retry for each sector can take seconds. Add to that the fact that the disk itself will read multiple sectors at once: if it reads a cluster of sectors of which multiple sectors can't be read the time required to recover from a read error per sector needs to be multiplied by the amount of unreadable sectors in this cluster of sectors.

Lowering the number of retry attempts by DiskPatch may reduce the time required to complete pass 2 and may result in smaller 'holes'. This is however no guarantee that copied volumes can be mounted afterwards. You may need to use something like iRecover to recover files. Smaller holes are better in that case as well: iRecover may find more file system structures, plus the chances that file contents are intact are better.

Note about running iRecover on the clone: In advanced configuration > NTFS TAB > set ignore gaps in MFT to half the skip value you used in DiskPatch.
Logged

--
Kind regards,
Joep - My blog @: www.disktuna.com - Try my JPEG Repair Tool: https://youtu.be/Ox2F8QRuU5Q
J
member

Posts: 20


« Reply #22 on: March 02, 2010, 12:09:34 PM »

Thanks for the explanation. So far these have been suggested and pending on me.

1. Select second volume and do repair on that instead in DP.
2. Do 2nd pass clone using DP with a lesser retry attempt parameter
3. Try iRecover.

I'll update on them when I have tried them. Takes very long!

Questions i have.

1. >If Windows displays the partition as RAW then critical file system structures are corrupt or haven't been copied.

DP reads the partition as NTFS. Is this an indication that the file system structure is not far too gone such that it is still recognisable by DP? Is this something that I can work on?

2. Is the file directory structure of all the files and folders stored on the disk kept in some kind of portion of the disk? If file recovery isn't possible, am I able to at least know what is the file and folder structures so I know exactly what I've lost. How can I go about specifically recovering this information?

What I've tried so far.

Am still doing a volume anaylsis with iRecover. The "map" screenshot is here - http://www.box.net/shared/2vbqqt1vsx
Really looks quite white for comfort. Does this map tell you anything?
Logged
Tom
Developer and Support Tech
Administrator
member
*****
Posts: 1476


WWW
« Reply #23 on: March 02, 2010, 12:24:18 PM »

Quote
DP reads the partition as NTFS. Is this an indication that the file system structure is not far too gone such that it is still recognisable by DP? Is this something that I can work on?
No and No. DP uses different methods to determine the volume type, and this has very little to do with recoverability when using a file recovery tool.
Quote
Is the file directory structure of all the files and folders stored on the disk kept in some kind of portion of the disk?
In a way, yes.
Quote
If file recovery isn't possible, am I able to at least know what is the file and folder structures so I know exactly what I've lost. How can I go about specifically recovering this information?
No. There's no easy way to do that and the complicated way is too bothersome to be practical. You could start looking around on the disk with a disk- or hex editor, or something like NTFS explorer, but that requires specialized knowledge.
Quote
Does this map tell you anything?
Sofar, that nothing much was found.
Logged

J
member

Posts: 20


« Reply #24 on: March 02, 2010, 01:49:50 PM »

Thanks for the explanation. So far these have been suggested and pending on me.

1. Select second volume and do repair on that instead in DP.
2. Do 2nd pass clone using DP with a lesser retry attempt parameter
3. Try iRecover.


Got this for two hours plus of waiting for the iRecover full scan http://www.box.net/shared/8sz8ek6861 Sad

Haiz.

Will proceed on 1. Select second volume and do repair on that instead in DP.
Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1476



WWW
« Reply #25 on: March 02, 2010, 02:39:27 PM »

Hello,

Running repairs in DiskPatch is useless at this point. Run iRecover again, this time in advanced options disable the quick scan (common file system analysis TAB).

On volume selection screen right click > define volume manually > enter start of volume (0 MB) and size of volume on original device in MB.

If still no luck then cloning with Diskpatch skipped most of the file system structures. The only option is then to re-clone and this time complete pass 2 with the settings we recommended before.
Logged

--
Kind regards,
Joep - My blog @: www.disktuna.com - Try my JPEG Repair Tool: https://youtu.be/Ox2F8QRuU5Q
J
member

Posts: 20


« Reply #26 on: March 03, 2010, 05:46:18 AM »

Hi Joep,

Hello,

Running repairs in DiskPatch is useless at this point. Run iRecover again, this time in advanced options disable the quick scan (common file system analysis TAB).

On volume selection screen right click > define volume manually > enter start of volume (0 MB) and size of volume on original device in MB.

No luck. Got the same error message as the screenshot I posted earlier.

Quote
If still no luck then cloning with Diskpatch skipped most of the file system structures. The only option is then to re-clone and this time complete pass 2 with the settings we recommended before.

I'm doing this now w a read retry attempt of 0 and to skip over 8 bytes.
Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1476



WWW
« Reply #27 on: March 03, 2010, 09:01:55 AM »

Hello,

You mean you skip over 8 sectors? yes that's another way of doing it however pass 1 may take a long time that way: bad sectors are often not alone but tend to be grouped. If assuming a group of 32 bad sectors DiskPatch will hit that group several times if it skips only 8 sectors after a read error. With a larger skip setting it would have hit one bad sector and then simply have skipped the whole bunch. On the other hand pass 2 would then take longer. The reason we go for skipping larger areas is to get as much data from a disk as possible without stressing it too much. Then after we have the largest portion of the data we allow more stress on the disk during pass 2. If a disk is close to going belly up, then this is the safest strategy.

Did you disable disk resets as well?
Logged

--
Kind regards,
Joep - My blog @: www.disktuna.com - Try my JPEG Repair Tool: https://youtu.be/Ox2F8QRuU5Q
J
member

Posts: 20


« Reply #28 on: March 03, 2010, 09:44:10 AM »

Hello,

You mean you skip over 8 sectors?


Ah yes I meant 8 sectors instead of bytes.

Quote

yes that's another way of doing it however pass 1 may take a long time that way: bad sectors are often not alone but tend to be grouped. If assuming a group of 32 bad sectors DiskPatch will hit that group several times if it skips only 8 sectors after a read error. With a larger skip setting it would have hit one bad sector and then simply have skipped the whole bunch. On the other hand pass 2 would then take longer. The reason we go for skipping larger areas is to get as much data from a disk as possible without stressing it too much. Then after we have the largest portion of the data we allow more stress on the disk during pass 2. If a disk is close to going belly up, then this is the safest strategy.

Actually I'm running only pass 2 as advised by Tom earlier (to continue with it). I assume that DP is filling up the gaps now from pass 1 completed earlier?

I find the speed a lot better with the manual settings. With default settings the last time I ran pass 2, I went at it for 48 hours and the progress bar didn't even move a notch. The time remaining was in the range of 6 digits (http://www.box.net/shared/nqo1q1v432). Now its relatively better, about 7000+ minutes, although I hope it doesn't mean that literally.

What I'm puzzled is though, why DP hasn't encountered any read errors yet. I'm already about 1 mark through the progress bar. During the first clone, there were lots of read errors. I hope this doesn't mean the disk is worse?

Quote
Did you disable disk resets as well?

Eh, sorry. What's that?
Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1476



WWW
« Reply #29 on: March 03, 2010, 09:54:59 AM »

hello,

Ok, pass 2. then skip setting has no effect at this point. The reduced number of retries should indeed make a difference.

Disk resets after error is on by default. Each disk reset may take some time, so that adds to the total time as well. Disabling this option may save some more time.

No read errors at all? Well if the disk would  be worse you'd get more read errors. I am becoming more and more curious what type of read errors we encountered. We haven't seen a log of that yet. if you still have the pass 1 log somewhere could you please email it (support@diydatarecovery.nl)?

Time required estimate is just that. As it skipped 1024 sectors suring pass 1 after a read error you'd normally expect the majority of the sectors skipped to be ok. So if it hits bad sectors at the start it estimates that (remaining sectors * time it took to read the bad sectors) as time remaining. Good sectors take less time. This will become more and more balanced as it proceeds.
Logged

--
Kind regards,
Joep - My blog @: www.disktuna.com - Try my JPEG Repair Tool: https://youtu.be/Ox2F8QRuU5Q
Pages: 1 [2] 3 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.20 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!