Random data with random seeking test pattern test failure

[xuhantao]

Hi, everyone

I tested an 1TB PCIe SSD drive on DELL T630 tower system with Burnin Test V8.0 PRO build 1041.

In Disk Test Suite, I choose physical raw drive test, block size 4 MB, 1% file size, default cyclic pattern.

I got multiple data verify failure (value read: 0 which expect non-zero value) during random data pattern with random seeking mode.

I know in V8.0 guide, it said random seeking mode doesn`t support physical raw drive test.

But if I choose default cyclic pattern which include random seeking mode, will test either skip the random seeking mode or do it anyway?

This is my failure trace:

LOG NOTE: Disk , WriteFile - opening raw disk: \\.\PhysicalDrive3

LOG NOTE: Disk , Seeking distance 0, to block number 2049 within file 3:\BurnInTest test files\~bittest300001

LOG NOTE: Disk , [3:] Reading block size 4194304

LOG NOTE: Disk , [3:] Verifying block of size 4194304

SERIOUS: Disk, 3: Data Verify failure

LOG NOTE: Disk, File: 3:\BurnInTest test files\~bittest300001, Value Read: 0, Value Expected: 233, Offset 0, Ops: 25565876715520

LOG NOTE: Disk, 3:\BurnInTest test files\~bittest300001, Block# 2048 (size 4194304), index 0, File# 1, Start File# 1, Blocks/file 2289, Filesize 9600761856

From the trace, I have couple of questions.

1) what does "seeking distance" means? it shows 0 before each value read 0 failure happened. Is it related to my drive`s LBA?

2) Since it`s not file system in raw drive, is there anyway that I can get that "bittest300001" test file? That may help with tracking failure block.

3)what does "offset 0" means? Is that somehow related to the block number to be verified?

This thread is a little bit long, really appreciated someone could take a look at it.

Thanks!

[Tim (PassMark)]

Could you please download and try the latest build to check you still see the same behavior (V8.1 build 1008, http://www.passmark.com/download/bit_download.htm).

I believe the line in the help file about the random seeking mode not being supported in the raw disk test is no longer true and was not removed when support was added, we'll remove this line for the next release.

1. This is the point in the file at which verification begins, it should be equal to the block size from the test options * (block number - 1), so 0 seems incorrect in this instance.

2. You would need to use a raw disk viewer (like the one available in OSForensics). BurnInTest will write 0 for the first 512 bytes and then start the first file. So in your example block 2049 in test file 1 should start at offset 8,589,935,104.

3. Offset is where in the block the verification error occurred, so 0 is the first byte.

[xuhantao]

Could you please download and try the latest build to check you still see the same behavior (V8.1 build 1008, http://www.passmark.com/download/bit_download.htm).

I believe the line in the help file about the random seeking mode not being supported in the raw disk test is no longer true and was not removed when support was added, we'll remove this line for the next release.

1. This is the point in the file at which verification begins, it should be equal to the block size from the test options * (block number - 1), so 0 seems incorrect in this instance.

2. You would need to use a raw disk viewer (like the one available in OSForensics). BurnInTest will write 0 for the first 512 bytes and then start the first file. So in your example block 2049 in test file 1 should start at offset 8,589,935,104.

3. Offset is where in the block the verification error occurred, so 0 is the first byte.

Hi, Tim

Thanks for your quick reply.

I saw that just after build 1041, the build 1042 kinda update the random seeking pattern.
So that means raw drive will be supported by random seeking since this , right?

And thanks for all the keywords explanation, really helpful.

I have updated the software to build 1008 and restart the test.

Just right now, the same read zero failure still happen.

So for this read zero failure, both "seek distance" and "offset" have been set to zero which cause the verification been navigated into first byte of raw drive. Since test suite will zero the first 512 bytes zone, I am interested in how the test set an expected value 244 but track the data from that zero zone?
I already use raw drive tool to scan the drive, it `s true that first 512 Bytes reading are all zero.

This is the brief of new trace:

LOG NOTE: Disk , WriteFile - opening raw disk: \\.\PhysicalDrive3

LOG NOTE: Disk , Seeking distance 0, to block number 2049 within file 3:\BurnInTest test files\~bittest300001

LOG NOTE: Disk , [3:] Reading block size 4194304

LOG NOTE: Disk , [3:] Verifying block of size 4194304

SERIOUS: Disk, 3: Data Verify failure

LOG NOTE: Disk, File: 3:\BurnInTest test files\~bittest300001, Value Read: 0, Value Expected: 244, Offset 0, Ops: 2079506563072

LOG NOTE: Disk, 3:\BurnInTest test files\~bittest300001, Block# 2048 (size 4194304), index 0, File# 1, Start File# 1, Blocks/file 2289, Filesize 9600761856

LOG NOTE: Disk , VerifyBlock dump 1: Written 244, Read 0

LOG NOTE: Disk , VerifyBlock dump 2: Written 34, Read 0

LOG NOTE: Disk , VerifyBlock dump 3: Written 24, Read 0

LOG NOTE: Disk , VerifyBlock dump 4: Written 33, Read 0

LOG NOTE: Disk , VerifyBlock dump 5: Written 243, Read 0 ................. LOG NOTE: Disk , VerifyBlock dump 512: Written 161, Read 0

It`s a little bit weird that the test is verifying the first 512 Bytes of block, shouldn`t that be all zero based on your settings? Looks like they are keeping writing value into the block, then all they got is zero

Appreciate your patience.

Thanks

[Tim (PassMark)]

Only the very first 512 bytes of the disk are set to 0 (not each file/test block). The seeing distance reported appears to be wrong and that is likely what is causing the verification failure, could you please email us a copy of the full log files so we can take a look at them in more detail.

* Update* It looks like we've been able to reproduce this so we'll continue to look into what the cause might be.

[xuhantao]

Only the very first 512 bytes of the disk are set to 0 (not each file/test block). The seeing distance reported appears to be wrong and that is likely what is causing the verification failure, could you please email us a copy of the full log files so we can take a look at them in more detail.

* Update* It looks like we've been able to reproduce this so we'll continue to look into what the cause might be.

Hi, Tim

I already send you the private message.

Thank you very much

[xuhantao]

Only the very first 512 bytes of the disk are set to 0 (not each file/test block). The seeing distance reported appears to be wrong and that is likely what is causing the verification failure, could you please email us a copy of the full log files so we can take a look at them in more detail.

* Update* It looks like we've been able to reproduce this so we'll continue to look into what the cause might be.

Also, Tim

I have a question about the calculation on offsets or seeking distance. I found one thread about it as below

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


So, "bittest200001" would be filenumber 1, so it doesn't matter what is the first digit but the last digit number, am I right?

And there is two lines from my log

LOG NOTE: 2015-08-15 06:34:12, Disk , Seeking distance 390070272, to block number 2142 within file 3:\BurnInTest test files\~bittest300002

LOG NOTE: 2015-08-15 06:34:12, Disk , [3:] Reading block size 4194304

My block size is 4 MB, file size is 9600761856 which is 1% of 1TB drives

((Blocknumber-1)*Blocksize) would be 2141*4194304 =8980004864

How does it calculate with the seek distance?

Thank you.

[Tim (PassMark)]

It looks like this was caused by a casting issue in BurnInTest during the calculation of the offset during the random seeking phase of the test. This would cause a 32bit overflow of the seeking value (from the example above, 8980004864 - 4294967296 (2^32) - 4294967296 (2nd 32bit overflow) = 390070272).

In the case when this overflow caused the seeking value to be 0, BurnInTest would be reading the first 512 bytes that have been set to 0 and log a verification error. This will be fixed in the next public build.