One of my LUNs (a Logical Drive on the VTrak) returns medium errors when accessed by the host and sometimes the LUN is inaccessible.

Examining the Error Table Info section of the Service Report, or executing the "checktable" command from the CLI, shows that there are entries in either the Read Check Table or the Write Check Table of the affected Logical Drive.

What does this really mean?

The Read Check Table is used to record the Logical Block Address (LBA) of any physical blocks that have invalid data - but the sector is physically good.

An invalid data block can be the result of an unrecoverable medium error being returned from a physical drive while being read while the Logical Drive it is part of is not in a redundant state because the RAID controller is unable to use parity (or mirror) data to re-generate and write the correct data to the drive. An example of this is when a RAID 5 Logical Drive is being rebuilt and it encounters an error while reading from one of the other member drives.

Note that these types of errors can occur when rebuilding a RAID 1 or RAID 5 Logical Drive, but a RAID 6 Logical Drive can recover due to its double parity structure.

When a Host reads the data from an LBA that is listed in the RCT a Medium Error will be returned back to the Host.
When a Host writes data to an LBA that is listed in the RCT the entry will be cleared. 


Here is an example of a Read Check Table from a VTrak's Service Report that shows one entry:

[LD1]
==================================================================
Read Check Table
==================================================================
==================================================================
SeqNo                   StartingLBA                    Count
==================================================================
0                       297472575                      1
==================================================================

The important thing to note is the Logical Drive ID for the table entries - in this case it is LD1 that has a read check error.


In order to identify which Physical Drive could be causing the read check errors, examine the Runtime and NVRAM Event Logs and look for any drive errors that may have occurred during the rebuild of an array.


Normally, running a file system check on the Host would re-write the block and clear the error, but in some cases the file system check may not repair the errors; please contact PROMISE Technical Support for help with this condition. It would be a good idea to backup the data for the LUN that is affected, because clearing the LBAs from the table will clear the data they contain.

Also note that if you are certain the data located at the LBA indicated is safe to lose, you can clear the Read Check Table manually by using the CLI - if your VTrak is running firmware version 3.32 or later. Perform this operation at your own risk!

WARNING: If the LBA which you are clearing contains valid data, the data on that block (sectors) may be lost. Please consult with Promise Technical support if you are unclear or unsure about this process.

admin@cli> checktable –a clear –t rct –l x

where “X” is the Logical Drive ID.


The PROMISE VTrak Service Report will list all Read Check Table entries, so if you need help determining the state of your Logical Drives, please have the Service Report available when contacting PROMISE Technical Support.
For instructions on saving a Service Report refer to KnowledgeBase Article 10095