PDA

View Full Version : Final adjustments 99% - 7 days - unable to continue


Merlin
4th April 2008, 02:56
We have been working with recovery from a damaged RAID5 for 7 days.
One drive is missing.
The two remaining drives had some media defects and have therefore been cloned to two new S-ATA drives.
File System is confirmed as NTFS.
As usual "Quick Identify Data" worked very fast in the beginning and slow down as the index (DataBase) increased in size.
After almost 7 days processing we reached the phase "Final adjustments" and the stage of the process reached 99%.
We were then greeted by the message "Unable to continue: Unable to reconstruct the RAID...."

http://www.aurora.se/zar/final_adjustments.jpg

We are using a powerful dual-processor based system, XP-Pro, 2GB RAM, a separate 500GB drive for recovered data. Logical E: We have configured Windows to assign virtual memory as needed including use of drive E: Thus there should be no problems with space for temporary files.

We have observed that during the "Quick Identify Data" phase, the read cache was using no more than 200MB at any time. We had allowed 500MB on the runtime control. However, when the system failed, we noticed that the read cache indicated that almost all of the read cache was allocated, 474MB of the available 500MB.

We purchased a license only a few weeks ago, and accordingly have very limited experience with your product. The above situation has occurred on several different occasions.

your advice would be appreciated.

Lara

Merlin
4th April 2008, 03:31
We attach the beginning and the end of the log file.
maybe this is of some assistance:


Init done - logging
NT 5.1.2600 Service Pack 2; 2047 MB RAM
Open physical drive 00000100 success, 76319 MB : ST380811AS - Port 2, Bus 0, Target 0, LUN 0; maxLBA=156301488
Open physical drive 00000101 success, 69464 MB : ST380817AS - Port 3, Bus 0, Target 1, LUN 0; maxLBA=142264000
Open physical drive 00000102 success, 372 GB : ST340083 2AS - Port 7, Bus 1, Target 0, LUN 0; maxLBA=781422768
Open physical drive 00000103 success, 69464 MB : ST380815AS - Port 2, Bus 0, Target 1, LUN 0; maxLBA=142264000
Starting RAID5 parity check
Parity detected in 75% of 200 tests
Raw scanner starting on disk 0101 from LBA 0 to LBA 142264000
Raw scanner starting on disk 0103 from LBA 0 to LBA 142264000
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 5839F704
ALERT!: MFT entry with alloc size 4318 was encountered during identification; Base record ID 4B630000
ALERT!: MFT entry with alloc size 5494 was encountered during identification; Base record ID 266584C4
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 5807C1C4
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 001800
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 585384C4
ALERT!: MFT entry with alloc size 1288 was encountered during identification; Base record ID 001131
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 850C72C4
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 851A1104
ALERT!: MFT entry with alloc size 41251 was encountered during identification; Base record ID EAE60000
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 847E2284
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 847EFC44
ALERT!: MFT entry with alloc size 0 was encountered during identification; Base record ID 84872304
QS LSIDE: 33241
QS RSIDE: 3191
QS LSIDE: 28170
QS RSIDE: 3406
AS start
Performance: Ident data query (0 of 0) 0s
Performance: Ident data query (47157 of 47157) 0s
Performance: Ident data query (0 of 0) 0s
Performance: Ident data query (52285 of 52285) 0s
AS done
Performance: Ident data query (43748 of 47157) 0s
RAID: fetch 43748 entries, drive 0101
Performance: Ident data query (49085 of 52285) 0s
RAID: fetch 49085 entries, drive 0103
Volume information:3.0
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000

---------------------

this is the end of the logfile:


ALERT!: Excessive MFT attribute size near ap 342; hint -1
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
ALERT!: SEQ 0x0000
Performance: BuildSwitchList 49s
Vote RAID stripe size: 32; Count=1961 ; separation 99,7%
Purged a total of 9700 known false positives (stripe size mismatched)
Remaining 3899 records
Vote Start offset: 0; Count=3874 ; separation 99,9%
RCRD/RSTR bias @3812
RAID: Test RAID0
Performance: Ident data query (2484 of 45548) 0s
Parity for disk 0101 at 2
Too low separation (766 vs. 851)
Final nonzero RAID layout scores
UNABLE TO CONTINUE:
Unable to reconstruct the RAID
Unable to continue processing, program will now terminate.
Not a bug - data is probably beyond repair, or something is misconfigured.

Spasibo

Lara

Alexey V. Gubin
4th April 2008, 07:17
What is the build number indicated on the first screen when you start ZAR?

Merlin
4th April 2008, 07:47
We use following version ZAR 8.3 build 29

Alexey V. Gubin
4th April 2008, 12:05
We looking into it. Looks like we encountered something like this already, but I cross checked the fix against your log fragment and found that the fix is not efficient enough. So that requires little more work. Expect I will have something you can try... in 24 hours perhaps.

Merlin
4th April 2008, 12:20
Very many thanks for your outstanding service Alexey,
we look forward to any patches,
_____________
Spasibo !
Tony

Alexey V. Gubin
5th April 2008, 08:27
Try this one - http://www.z-a-recovery.com/zar-83-034.exe
This should be faster than previous, 7 days is waaaay to long. Next time, do not wait that long. General rule is that if you exceed 24 hours run time, you start looking around for a problem. Except for a physical damage.