Hard Disk Monitoring

Disk capacities get bigger and bigger and so surface tests take longer and longer.

It would be great if I could stop such a test and resume it at the stopped position at a later time. HDS should keep this position and ask me at a new scan if I want to start from there. Even more perfect would be if it logs this position to be able to resume at an unexpected system shutdown (log only every couple of minutes).

It would be great if I could set a stop temperature. If this temperature is reached the surface scan stops. But I should be able to resume later from this position.

It would also be great if I could enter start and end values like HD Tune Pro has it at the Error Scan. This is useful if I find a certain problem area at the disk and want to scan only this area again.

You can any time save the current (even partial results) during the test in the following ways:
- if you prefer to save an image about the disk surface map, please use the small floppy disk button in the upper right corner of the disk surface test window
- if you prefer to save more detailed information, please right click on the disk surface map and select Save disk information (which can be re-load later in the software) or Export transfer speed values (which can be loaded in for example Excel).

There is no need to save the scan and the re-load it, because before starting the test, you can configure which particular block(s) you prefer to be tested.
For example if you save the (partial) results when the first 20% (2000 blocks) tested, then you can use:

Disk -> Surface test -> and in the new window when you select the test, select Configuration tab and use the "Limit testing to specific data blocks" option, to specify First block = 2001 and Last block = 9999.
This way the test will start from that specific block, so there's no need to test the previous 2000 blocks again.

Ps. This is already answered in an other topic: viewtopic.php?f=8&t=2253

So as you can see, Hard Disk Sentinel already has the options the other tool you menioned ....
Yes, the "temperatre limit" to stop may be a good idea, thanks for the suggestion!

Thank you for your response!

Sorry - I looked in the help file and did not find anything about it. Will use this in HDS as soon as my system is repaired. Have to check the replacement disk anyway.

Allow me one more question. Let's take an example. The surface read test takes for instance 3 hours. The write test takes for instance 3 hours. But this refresh test (read/write) takes far more than 20 hours (I did not finish it - just saw the displayed time). Why is this huge difference? Could not be done in let's say 6 or 7 hours? Is this because there are no buffers used or why?

By the way - I tested a single disk of my RAID 0 array (took it out there) with this refresh read/write test for about two hours and then stopped it because it would have taken 23 hours. Then I put it back into the RAID array. No problems. Worked perfectly again! Great software

> Sorry - I looked in the help file and did not find anything about it.

Sorry The Help -> Hard disk tests -> Surface test page (or simply pressing F1 or the Help button in the new window when Disk -> Surface test option selected) may display this information

> Allow me one more question. Let's take an example. The surface read test takes for instance 3 hours.
> The write test takes for instance 3 hours. But this refresh test (read/write) takes far more than 20 hours
> Could not be done in let's say 6 or 7 hours? Is this because there are no buffers used or why?

No cache used of course during the test (otherwise it would be not too useful - as it is required that we really write to the device, not to the cache).

6-7 hours is not really possible because if you add
3 hours (simply READing the complete surface)
3 hours (simple WRITing to the complete surface)
3 hours (READ back the contents and compare with the original - as it is the main purpose of the "READ + WRITE + READ" test)
we have 9 hours total.
The above steps are described in the 1st sentence of the description of the test:
"Reads stored data from each blocks, writes back the contents and finally reads the information and compare with original contents."

Why it is longer? Just read the next sentence of the description of this READ + WRITE + READ "refresh data area" test before starting the test:
"By the extensive test, an additional write cycle is used before writing back the contents to improve the efficiency of the error correction (drive regeneration)."

This means that the software will
- read a sector
- overwrite the sector with special pattern
- write back the original contents
- read back and compare the data with the original contents, to make sure the data is 100% same (no verification error).

This "extensive test" (extra step) is enabled by default, it can be disabled if required on the menioned Configuration tab of the new window opened when you use Disk -> Surface test.

Please note that usually write operations take longer than reads, this is normal for both hard disks and SSDs.

I will check the help file when I have the software installed again to get information about resuming the tests. But now I not that it should be possible.

In respect of the cache it was not my idea that you write into a cache - of course this does not make sense at all. The idea was that you read a certain amount of disk data into a cache and then write sequentially out of this cache so that you do not have too many (empty) disk turns to get to the correct position on the disk again. The idea was to reduce the time for positioning. But I guess you do this anyway.

Thank you for your support again.

Just a tip: the help is available online also at www.hdsentinel.com -> Support -> Complete Help
directly at: http://www.hdsentinel.com/help/en/index.html

> The idea was that you read a certain amount of disk data into a cache and then write sequentially out of this cache
> so that you do not have too many (empty) disk turns to get to the correct position on the disk again.
> The idea was to reduce the time for positioning. But I guess you do this anyway.

Yes, I can confirm that things work exactly as you wrote: the processing of the blocks are done sequentially (without using the cache) to process the sectors as fast as possible, minimising the time required to positioning.