Searching: service report - 32 Results Found

VESS Other Saving a System Service Report for the VessRAID
Ken Chou posted this 31 August 2009

If you need to contact Promise Technical Support you will be asked to send the System Service Report, which will include all of the information necessary for them to check the status of your VesssRAID.

The VessRAID provides two simple methods for collecting and saving a System Service Report.

WebPAM PROe

The first method - shared by all Promise subsystems - is by using the WebPAM browser-based management interface.

Log in to the subsystem and click the VessRAID item under the Subsystems item at the top. 

This will display the Information tab; click the Save button.

Wait for 10 to 20 seconds for the Save File dialog and select a location to save the report.

OPAS

The second method - introduced with the VessRAID - is to use the One Plug Auto Service tool that uses a USB Flash Drive to save the data. This process is entirely automatic and does not require you access the management menu.

Plug a USB Flash Drive into one of the USB slots on the back of the VessRAID.


The USB status light will start blinking amber . This indicates that  the Subsystem Report is being saved on the USB Thumb Drive. The light will continue to blink until it completes the creation of the subsystem report.



When the USB Status light becomes a solid green light, the scanning and saving of the file will be complete.

You can plug the USB Flash Drive in to the USB socket of your computer and open the folder for it.

There you should find another folder called "OPASOUTPUT", and in there will be a file whose name will be formatted similar to "OPASsubinfoYYMMddhhmmss.html". This is the file that you need to email to the Promise technician working on your issue.

The filename will be composed of these elements:
"YY" indicates the Year (Example: 2009 will be 09)
"MM" indicates the Month (Values 01-12)
"dd" indicates the day of the month(Values 01-31)
"hh" indicates the Hour , 00-23
"mm" indicates the minute(Values  00-59)
"ss" indicates the second(Values 00-59)

EXAMPLE: The report "OPAS
subinfo_090717133456.log" was taken on July 17, 2009, 01:34:56 PM.


Troubleshooting

A Red LED after the flashing Yellow LED indicates that saving the service report file has failed.

  • Please check if your USB drive is full and reinsert the USB drive to try again.
  • If it continues to fail, please call Promise Technical Support to troubleshoot the issue further.

No LED after plugging your USB Drive in to the socket may indicate that the VessRAID is not recognizing your USB Drive.

  • Remove and re-insert the USB Drive to see if the VessRAID can complete discovery.
  • Try a different USB Drive, or test it on a computer to ensure that it is still functional.
  • Try another USB Drive type, as this one may not be compatible with the VessRAID.

Note: If you were to plug in the USB drive into another VessRAID within One Minute of taking it out of another VessRAID, OPAS would overwrite the generated file that was saved by the previous VessRAID. You should wait at least one full minute before plugging the USB drive into another VessRAID so that the file name can have a different time stamp.




Legacy Other KB 10144 - My Host reports Medium Errors trying to access LUNs on my VTrak
Ken Chou posted this 05 February 2009


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



Close