Raw scan time on RAID5 volume

[crashed]

This is a Windows Server RAID5 volume made up of four 500GB WD RE drives. The filesystem became corrupted when the drive bay system failed electrically. The drives are now cabled directly to the 4 motherboard SATA connections.

ZAR identified the drives, did its RAID discovery stuff, and I selected the NTFS volume from its list of possibilities. Now, during the 2nd half of "Raw scan: Quick", the percentage indicator isn't changing. I let it go for an hour last night but it remained at 0%. Disk i/o was low and CPU utilization was high so I quit and installed an Opteron in place of the single core CPU to help overnight progress. This morning the map shows much more blue and green than before - I'd estimate 5% - but the percentage indication still hasn't changed from 0%.

Both cores are pegged - 195-200%.
Elapsed time is 9h 39m.
Read cache is at 511MB of 512
RAID disk i/o is intermittent.
I looked for a logfile but don't see anything changed in the ZAR directory besides the autosaves.

Any suggestions?

Thanks.

[crashed]

If it matters, there are no red blocks at all. The drives behave normally and SMART indications are good.

[Alexey V. Gubin]

How many files do you think you have on this volume?

If you do not see a log file,
1. kill the current run
2. restart ZAR
3. on the first screen click "Advanced Configuration"
4. in there, under "General" change "Logging" from "Normal" to "Extended (for debugging)". Also take note of where the log file should be.
5. Re-run same as previously
6. About ten minutes into the run, check to make sure if the log file is there and grows.

note that in "normal" mode the log is buffered, any of the debugging modes is unbuffered.

[crashed]

There are probably 70-100 thousand files, much of it media, though I don't recall the last time I noticed a count.

The log was set to use my temp directory. Good to know about running buffered/unbuffered.

I went through the process again, letting it run the Raw scan: Quick - identifying data portion for 14 minutes. The behavior seems identical, except in this case I'm left with a 130,112,820-byte logfile.

BTW, clicking Exit prompts "are you sure". Clicking Yes appears to close the logfile and stop the timer, and the "exit start" is logged, but the program won't exit or give up CPU time in spite of repeating the last two steps. I let it run a while in case it was chewing on the 512MB read cache. No change. This happened last run, too, though it did seem to close without complaint when I shut down.

Possibly useless note: It appears cpu usage changes once zar gets stuck. While it normally dips here and there, once it gets stuck and I try to exit, the utilization pegs at 100% with a solid line in Task Mgr. Something's in runaway.

Near the end of the logfile are four "Memory Status" lines. Is something exhausted?
00000B74: MEMORY STATUS: Address space: 556 MB; Alloc: 532 MB; Free: 23393 KB; Small: 1900 KB; Big: 21245 KB;

I'm going to try one more time with a minimal cache and file verification disabled. Might try bumping up the maximum resolver size. Reaching here. Whatever you can suggest will be appreciated.


Thanks.

[Alexey V. Gubin]

"MEMORY STATUS: ..." is a debug heartbeat, recorded every several megabytes of data transfer from the disk. The parameters you cite look good, though.

Is it possible that you ZIP the entire log file, upload it somewhere, then send me an URL (either with a private message, or email to development@z-a-recovery.com)?

Alternatively, I've sent you a private message with our own FTP login information to upload to.

[Alexey V. Gubin]

Could you please try

0. Delete the log file, so we have a blank one to start with. I have the first log file archived should we later need it for reference.
1. Have ZAR rebuild a RAID once again.
2. When it prompts you to select a volume, do not use any of the existing volumes. Right click the volume list instead, and pick "Define volume manually".
3. A window appears prompting you if there was only one volume, or if you want manual parameters. Pick "There was only one volume" and click OK.
4. ZAR will return to the list of volumes, and a new volume should be listed with the "Unknown" file system type and the origin indicated as "User input".
5. Have ZAR scan this manually-defined volume.

see if maybe this resolves the problem.

[crashed]

Wow. I haven't seen those files in a while.

Trying to contain myself here. I stupidly left validation off after my previous attempt, but this looks far better than anything I've seen before. (Any way to run validation after file discovery?)

I'm saving state and re-running with validation while I head to a meeting at which I'll be struggling to pay attention.

I've tried every utility I could find, with dismal results, until now.

Back with a final report later.

[Alexey V. Gubin]

No, if the validation is off, then it is off. Validation needs certain data to be collected during scan. This data collection is not performed when the validation is disabled.