Is "block num" equal to LBA?

[CJones]

Hi all,We ran into a problem when running a test on a drive. The error is indicated below... - start of log******************DETAILED EVENT LOG******************LOG NOTE: 2011-10-13 17:28:26, Status, PassMark BurnInTest V6.0 Pro 1019LOG NOTE: 2011-10-13 17:28:26, Status, Main Tests startedSERIOUS: 2011-10-13 18:43:05, Disk, 1: Error while reading from the diskLOG NOTE: 2011-10-13 18:43:05, Disk, Verify Read File: 1:\BurnInTest test files\~bittest100001, Block Size: 262144, Block Num: 376383, Ops: 201745498112LOG NOTE: 2011-10-13 18:43:05, Disk, The request could not be performed because of an I/O device error. (1117)LOG NOTE: 2011-10-13 18:43:05, Disk, Disk Error (1: Error while reading from the disk in Cycle 0 with pattern Sequential data pattern LOG NOTE: 2011-10-13 18:43:11, Status, Test run stopped******************- end of logIs the "Block Num: 376383" indicated in the log corresponds to the logical block address (LBA) of the drive currently being accessed by BurnIn test at the time of failure?Thanks in advance.Best regards,CJones

[Ian (PassMark)]

The block number in this log file is not the same as the LBA. BurnInTest creates test files and the block number is the block number within a particular test file, where the block size is defined in Preferences->Disk.

This looks like a disk problem and I would consider trying a different disk.

Also, I note you are using an old build of BurnInTest V6.0.1019. I would recommend upgrading to the latest build of BurnInTest V6.0 available from the bottom of this page:
http://www.passmark.com/download/bit_download.htm

[CJones]

Thanks Ian.

So it might be possible that BurnInTest will report a different block number for the same failing LBA every time the test is repeated? Is there a way we could equate the block number within the test file created by BurnIn test to the drive's LBA on a particular instance? We are currently doing a failure analysis on this drive so we are more interested to know the actual LBA where the test fail. Thanks again.

We'll look into the new build of BurnIn Test v6.0, thanks.

[Ian (PassMark)]

For the BurnInTest disk volume test (e.g. disk C:\), the location of the file on the physical disk will be determined by the Operating System and File System and this could change each test run. You could (with some effort) determine the location on the physical disk if you started BurnInTest with the "-k" command line parameter, which basically stops the disk test on an error and keeps the test files so they can be analyzed. You could then use a raw physical disk viewer to find the file, and block within that file on the physical disk.

An easier way may be to use the BurnInTest physical disk test (e.g. physical disk 0). This operates directly on the raw disk (i.e. not on the file system) and the physical location of the test data 'files' is controlled by BurnInTest. The physical disk test will destroy any data on the disk. In BurnInTest V7.0, the physical disk test is available on formatted disks (that do not contain Windows installations or paging files) or unformatted disk. In BurnInTest V6.0 the physical disk test is available on unformatted disks. If you want to use this mechanism, let me know and I will describe how the files are layed out on the physical disk.

[CJones]

That would be perfect, Ian. We'd love to know about it. We are actually testing the drive as physical disk. Thanks again.

[Ian (PassMark)]

The file size is defined as a % of the total disk in Preferences->Disk.
The block size is defined in Preferences->Disk.

The physical disk test opens the physical disk and writes files from 1..n from offset 0 to the end of the disk.
Each file is written 1..m blocks.

So, a write or read error reported on a block in a trace file is at the following offset on the physical disk:
((FileNumber-1) * filesize) + ((Blocknumber-1) * Blocksize)
except where Blocknumber equals 0, in this case it is:
((FileNumber-1) * filesize) + (Blocknumber * Blocksize)

As an example:
LOG NOTE: 2011-10-19 15:08:25, Disk , Writing file: 2:\BurnInTest test files\~bittest200001, size: 1048576
...
LOG NOTE: 2011-10-19 15:09:28, Disk, Write File 1: 2:\BurnInTest test files\~bittest200001, Block Size: 524288 , Block Num: 3, Ops: ... (B)

bittest200001 -> Filenumber = 1

This block number 3 will be at the following offset on physical drive 2:
((FileNumber-1) * filesize) + ((Blocknumber-1) * Blocksize) = ((1-1) * 1048576) + (3-1 * 524288 ) = 1048576 bytes

[CJones]

Thanks for the support, Ian. I think it's all we need.

[xuhantao]

The file size is defined as a % of the total disk in Preferences->Disk.
The block size is defined in Preferences->Disk.

The physical disk test opens the physical disk and writes files from 1..n from offset 0 to the end of the disk.
Each file is written 1..m blocks.

So, a write or read error reported on a block in a trace file is at the following offset on the physical disk:
((FileNumber-1) * filesize) + ((Blocknumber-1) * Blocksize)
except where Blocknumber equals 0, in this case it is:
((FileNumber-1) * filesize) + (Blocknumber * Blocksize)

As an example:
LOG NOTE: 2011-10-19 15:08:25, Disk , Writing file: 2:\BurnInTest test files\~bittest200001, size: 1048576
...
LOG NOTE: 2011-10-19 15:09:28, Disk, Write File 1: 2:\BurnInTest test files\~bittest200001, Block Size: 524288 , Block Num: 3, Ops: ... (B)

bittest200001 -> Filenumber = 1

This block number 3 will be at the following offset on physical drive 2:
((FileNumber-1) * filesize) + ((Blocknumber-1) * Blocksize) = ((1-1) * 1048576) + (3-1 * 524288 ) = 1048576 bytes

Dear Ian

Is it true that since Burnin Test V8.0 `s trace already give out the exact offsets automatically if data verify failure happened?

Thank you very much.

[Tim (PassMark)]

If there is a data verify failure the File number, value read/expected and offset will be added to the normal log file (not just the trace file).