Page 1 of 1

BIOS int 13h: WRITE test vs WRITE + READ test

Posted: 2015.08.01. 08:51
by jack150731
I've been trying to understand WRITE test vs WRITE + READ test. On the surface these two tests are kind of similar.

"WRITE test - Overwrites the disk surface with configurable pattern. Forces the analysis of any weak sectors and verifies any hidden problems and fixes them by reallocation of bad sectors (this is drive regeneration)."

"WRITE + read test (Pro version only) - Overwrites the disk surface with configurable pattern and then reads back sector contents, to verify if they are accessible and consistent. Forces the analysis of any weak sectors and verifies any hidden problems and fixes them by reallocation of bad sectors (this is drive regeneration)."

I guess eventually BIOS int 13h is called to run these tests. To better understand these two tests, I translated the above descriptions into the following pseudo code.

Code: Select all

WRITE test:
    // Forces the analysis of any weak sectors and verifies any hidden problems and fixes them by reallocation of bad sectors (this is drive regeneration).
    do {
        do {
            call int 13h, ah=3h;    // like DOS copy without /V
        } until (errorCode==0);
        call int 13h, ah=4h;
    } until (errorCode==0);

WRITE + READ test:
    // Forces the analysis of any weak sectors and verifies any hidden problems and fixes them by reallocation of bad sectors (this is drive regeneration).
    do {
        do {
            call int 13h, ah=3h;    // like DOS copy without /V
        } until (errorCode==0);
        call int 13h, ah=4h;
    } until (errorCode==0);

    // reads back sector contents, to verify if they are accessible and consistent
    call int 13h, ah=2h;
    if (errorCode==0) then {
        cmp read with written;
    }
Would you please confirm whether the translation is correct?

Thank you very much.

Re: BIOS int 13h: WRITE test vs WRITE + READ test

Posted: 2015.08.01. 14:35
by hdsentinel
First of all, I can confirm that the hard disk test (and Hard Disk Sentinel in general) does not use BIOS int 13h (BIOS in general) to address the hard disks, to access disk status information or any data sectors. Under Windows systems (since Windows NT4) do not the BIOS. Windows 95/98/ME were different, but newer, modern OSes do not allow using the BIOS.

Generally, the WRITE test performs a simple write - and the WRITE + READ test performs a complete write AND THEN a complete read.
This is why if you start both and cancel them, they look 100% similar - as the READ part in the "WRITE + READ test" occurs only after the complete surface overwritten, exactly to

- prevent possible caching effect of the hard disk, controller. Hard Disk Sentinel automatically disables write cache for the test, but in special conditions (eg. by special RAID controllers) writes may be cached.
And in the "WRITE + READ test" we want to read data back from the data sectors (the hard disk surface), not retrieve a cached data

- confirm if the complete surface (all data sectors) overwritten as should. In some rare cases, the write heads of the hard disk may be damaged and while it reports no problems, the data is not really written to the actual sectors. By the "WRITE + READ test" it is possible to confirm if the data is really written back, exactly because it reads back in a separate step, when the complete write function finished.

Re: BIOS int 13h: WRITE test vs WRITE + READ test

Posted: 2015.08.21. 22:33
by jack150731
Thank you very much for the detailed explanation.

If I understand you correctly, the write process doesn't guarantee the data is written to the disc media, and as long as the write process doesn't report any error, it is deemed the data is written successfully. Understanding low level details can make sure this tool is being used in the right way.

I've been using this tool to check all my hard disks, old and new. Everybody who owns a computer should get the Pro version.

BTW, I have a license question. If the tool is installed on a hard disk, then the disk is imaged by Acronis True Image (no sysprep) and restored to another disk, both disks are configured to be used only on the same computer, only one disk can be used at any time, how many licenses will be used? I'm in the process of replacing the system drive of one of my computers, and I'm wondering whether I can install it now or wait for the new system drive not to waste a license.

Your help is really appreciated.

Re: BIOS int 13h: WRITE test vs WRITE + READ test

Posted: 2015.08.22. 06:26
by hdsentinel
The write process should not use any disk cache or so, it forces the system to bypass the write cache (even if enabled). It is designed to target directly the surface, exactly to make sure the data is really written to the disk media. Some very special RAID controllers may make some caching, but this can be bypassed if you configure the test to repeat 2 times.

I can confirm that there will be no lost of license if you image / restore the system (even to a different hard disk or SSD).
The license is counted for the actual system and if you image / restore on the same computer (even with replaced system drive), the license is not wasted: the previously registered and activated license will continue.

Re: BIOS int 13h: WRITE test vs WRITE + READ test

Posted: 2015.08.22. 17:24
by jack150731
Thank you very much for confirming that no license will be wasted as long as it's on the same computer.

I understand now that WRITE test doesn't use any disk cache. The following statement has been intriguing me.
WRITE test - Overwrites the disk surface with configurable pattern. Forces the analysis of any weak sectors and verifies any hidden problems and fixes them by reallocation of bad sectors (this is drive regeneration).
How does WRITE "forces the analysis of any weak sectors and verifies any hidden problems"? I thought that except the error code / return code, a WRITE operation can't guarantee a sector was written to the surface successfully without reading it back and compare.

For example, when we "copy" a file, once it's copied without any error message, the copied file will not contain any bad sectors (at the moment), and if we don't use /V option, we can't know for sure "that new files are written correctly".

Re: BIOS int 13h: WRITE test vs WRITE + READ test

Posted: 2015.08.23. 01:08
by jack150731
When burning CD/DVD, there's verify option; if it's not verified, there's a possibility that the media is not burnt correctly. When copying files, there's verify option; if it's not verified, there's a possibility that the files are not copied correctly.

The low level disk write, like hdparm --write-sector, bypassing the block layer mechanism, analyses the written sector and re-allocate if necessary. Does that mean the low level write include verify option automatically?

To make sure a sector is not bad, different patterns need to be written and be read back to verify. In fact what we really need is just ONE verification. As long as what is read back is the same as what was written, the sector is usable at the moment, even if the sector could be a bad one. The re-allocation can be delayed until it is found to be bad.

If the low level write is guaranteed, the high level write "should" be guaranteed too, assuming everything else (especially the path from high level write to low level write) is working correctly, which unfortunately can't be guaranteed. So maybe that is the reason we also need high level verification when burning CD/DVD and copying files?

Re: BIOS int 13h: WRITE test vs WRITE + READ test

Posted: 2015.09.01. 10:32
by hdsentinel
> The low level disk write, like hdparm --write-sector, bypassing the block layer mechanism,
> analyses the written sector and re-allocate if necessary.
> Does that mean the low level write include verify option automatically?

I suspect you mean bypassing the file system and accessing directly the physical sectors.
Yes, this is how the tests in Hard Disk Sentinel work.
This is why the Hard Disk Sentinel surface test can test hard disks even
- if they have no partitions at all (empty, new or completely clean)
- if they have partition(s) unavailable for Windows (Linux / MAC partitions)
- if they have damaged NTFS / FAT / FAT32 partition(s) which are not readable by the system.

The Disk menu -> Surface test -> WRITE + Read test performs write and then (after the write pass completed) reads and verifies the written data.

Also the Disk menu -> Surface test -> Reinitialise disk surface performs write (with multiple passes, with different overwrite patterns) and then performs read + verify of course, to ensure that the sector is both write-able (with different patterns, which would help the

The Disk menu -> Surface test -> WRITE test performs a simple write (without read / verify).

> To make sure a sector is not bad, different patterns need to be written and be read back to verify.
> In fact what we really need is just ONE verification.

This is exactly the purpose of Disk menu -> Surface test -> Reinitialise disk surface test: this performs 100% this.


> If the low level write is guaranteed, the high level write "should" be guaranteed too,

If I understand correctly what do you mean about "high level write" (I assume you mean writing files on the actual file system), then no, I do not really agree.
Even if low level write is guaranteed, writing files to the file system may be cached and/or otherwise affected (for example real-time compression / encryption) which may affect how and when (if there is a delay) the data actually written.
Also faulty RAM may cause damage in this compressed / encrypted data - which may not affect low level writes.

Ideally, if there is no problem with the RAM, no problems in the operating environment (good cables, connections, stable power source, no CPU overclock or so) then the low level testing and verification is the best way - as this ensure that the storage system (the hard disk itself and related devices) are operating perfectly.
OR - these tests may reveal problems in this storage system (NOT only the hard disk itself but related devices like cables/connections/controller/drivers), for example
- data communication problems ( http://www.hdsentinel.com/hard_disk_cas ... _error.php )
- new weak sectors ( http://www.hdsentinel.com/hard_disk_cas ... ectors.php )
or so.

Re: BIOS int 13h: WRITE test vs WRITE + READ test

Posted: 2015.09.01. 14:00
by hdsentinel
> How does WRITE "forces the analysis of any weak sectors and verifies any hidden problems"?

Generally write operations trigger hard disks to examine the integrity of the weak sector(s) and reallocate - if the sector confirmed that it is really bad and needs reallocation.
Otherwise, if the sector found to be good, the write operation "clears" the weak status of the sector and restore its status to normal.


> For example, when we "copy" a file, once it's copied without any error message,
> the copied file will not contain any bad sectors (at the moment), and if we don't use /V
> option, we can't know for sure "that new files are written correctly".

Yes, this is true: if you simply perform a write test, you may be not 100% sure that the data is really written.
This is why I more recommend the use of Disk menu -> Surface test -> Reinitialise disk surface, as this performs multiple writes (with different patterns, exactly to make the above described repair function more effective, as then the firmware of the hard disk drive easier recognise problems) and also performs the read and verify function (not only check if the data can be read back - but verify if the proper data written).

Just as this is a really slow procedure, some users may prefer to save time by using
- Disk menu -> Surface test -> Write + Read test (single pass write and then read back)
or
- Disk menu -> Surface test -> Write test (just for overwrite)