Alexey V. Gubin
22nd June 2007, 14:47
Here are some estimations of the run time, from the start of scan to the point when file/folder tree is displayed.
With a hard disk, expect about 1 gigabyte per minute. Larger disks tend to be faster than that (up to 2GB per minute).
120GB HDD = two hours.
300GB HDD = four hours.
Digital image recovery (from a flash card) - expect two hours per run maximum if the read cache size is at least 64MB.If the run is taking longer, look at the colored volume map and the analysis stage indication.
If recovering digital images and the memory card is in the camera (i.e. the camera's own connection is used)
You need to use the card reader device. Certain camera drivers tend to choke on a damaged card. Remove the card from the camera and use the card reader device.
If the stage is listed as "Raw scan: identifying...", and there are red dots on the map: there is a physical problem with the device.
Without stopping the scan, in the runtime control panel
set Timeout to 200 ms
set retry attempts to 0
enable "Avoid repeated retries"
set skip factor to 8
Observe the progress for about fifteen minutes. If no speed boost
increase skip factor to the maximum allowed
enable "Force device/bus reset".
If this still does not improve speed, there is nothing more we can do (in software) to resolve the problem. For additional considerations refer to
Physical access problems with hard disks (http://www.z-a-recovery.com/physical-hard-drive-failure.htm).
Physical access problems with flash memory (http://www.z-a-recovery.com/physical-flash-memory-failure.htm) (USB sticks, memory cards).
It is recommedned that you abort the scan at this point, to avoid stressing the device.If the stage is listed other than "Raw scan", and no red dots on the map: there is a problem parsing the filesystem.
Check if the "Elapsed time" counter still moves. If not, close the program and report the problem.
Check CPU usage (with Task Manager) and disk activity.
Check if the log file (C:\Program Files\ZAR\logfile.txt) grows in size.
For additional ten minutes, observe
If CPU usage is low, no disk activity, and log file does not grow - close the program and report the problem.
If program seems still working on something, leave it alone for additional two hours. If still no progress - close and report.
What we need to investigate a filesystem analysis problem
Filesystem type (FAT/NTFS/ext).
for a FAT filesystem, if it is FAT16 or FAT32 (if known).
for a ext (Linux) filesystem, if it is ext2 or ext3.
Log file. Open the log file (C:\Program Files\ZAR\logfile.txt) and look at the end of it. Last entries in the log file record what ZAR was doing before a failure occured. Copy the last about 100 lines (important: see note below) and provide it along with the problem report.
Anything else you consider relevant (like the original problem description).If the debug logging is enabled, the heartbeat entries will be recorded in the log file for each megabyte of data read. These entires look like
XXXXXXX: Local cache hit ratio: ... cache hits of 2047 requests
XXXXXXX: MEMORY STATUS: Address space: ...; Alloc: ...; Free: ...; Small: ...; Big: ...;
These entries only provide information about the memory and cache usage. In most cases, we only need an approximate number of these (how many of these were there at the end of log? 1, 10, or 100?). Scroll up until you see something other than heartbeat - this would be the useful information.
With a hard disk, expect about 1 gigabyte per minute. Larger disks tend to be faster than that (up to 2GB per minute).
120GB HDD = two hours.
300GB HDD = four hours.
Digital image recovery (from a flash card) - expect two hours per run maximum if the read cache size is at least 64MB.If the run is taking longer, look at the colored volume map and the analysis stage indication.
If recovering digital images and the memory card is in the camera (i.e. the camera's own connection is used)
You need to use the card reader device. Certain camera drivers tend to choke on a damaged card. Remove the card from the camera and use the card reader device.
If the stage is listed as "Raw scan: identifying...", and there are red dots on the map: there is a physical problem with the device.
Without stopping the scan, in the runtime control panel
set Timeout to 200 ms
set retry attempts to 0
enable "Avoid repeated retries"
set skip factor to 8
Observe the progress for about fifteen minutes. If no speed boost
increase skip factor to the maximum allowed
enable "Force device/bus reset".
If this still does not improve speed, there is nothing more we can do (in software) to resolve the problem. For additional considerations refer to
Physical access problems with hard disks (http://www.z-a-recovery.com/physical-hard-drive-failure.htm).
Physical access problems with flash memory (http://www.z-a-recovery.com/physical-flash-memory-failure.htm) (USB sticks, memory cards).
It is recommedned that you abort the scan at this point, to avoid stressing the device.If the stage is listed other than "Raw scan", and no red dots on the map: there is a problem parsing the filesystem.
Check if the "Elapsed time" counter still moves. If not, close the program and report the problem.
Check CPU usage (with Task Manager) and disk activity.
Check if the log file (C:\Program Files\ZAR\logfile.txt) grows in size.
For additional ten minutes, observe
If CPU usage is low, no disk activity, and log file does not grow - close the program and report the problem.
If program seems still working on something, leave it alone for additional two hours. If still no progress - close and report.
What we need to investigate a filesystem analysis problem
Filesystem type (FAT/NTFS/ext).
for a FAT filesystem, if it is FAT16 or FAT32 (if known).
for a ext (Linux) filesystem, if it is ext2 or ext3.
Log file. Open the log file (C:\Program Files\ZAR\logfile.txt) and look at the end of it. Last entries in the log file record what ZAR was doing before a failure occured. Copy the last about 100 lines (important: see note below) and provide it along with the problem report.
Anything else you consider relevant (like the original problem description).If the debug logging is enabled, the heartbeat entries will be recorded in the log file for each megabyte of data read. These entires look like
XXXXXXX: Local cache hit ratio: ... cache hits of 2047 requests
XXXXXXX: MEMORY STATUS: Address space: ...; Alloc: ...; Free: ...; Small: ...; Big: ...;
These entries only provide information about the memory and cache usage. In most cases, we only need an approximate number of these (how many of these were there at the end of log? 1, 10, or 100?). Scroll up until you see something other than heartbeat - this would be the useful information.