Sun Virtual Library Extension (VLE)
 

PLA-Support>Sun Systems>TAPE>Virtual Tape>SN-TP: VLE
 

In this Document

Symptoms

Cause

Solution

Created from <SR 3-8383830991>

Applies to:

Symptoms

 Under some circumstances with heavy IO load, VLEs running version 1.3.12 or earlier versions of the code may hang and panic. As a result of this specific panic, ZFS may mark the vsbpool as corrupted, leaving a number of VMVCs and vtvs in corrupted state.

Cause

 The root cause of the issue is the SAS HBA driver. When the SAS driver encounters an inbound IO queue-stall during heavy IO, all read/write operations to the disks can hang and VLE can get into a system-panic. As a result of the panic, VLE may end up with data-check errors on VMVC/vtv data.

Solution

Customer needs to work the local field engineer and support team to recover the data. The data recovery procedure may require that the VLE or VLEs encountering the issue may need to be off-lined. Automatic recovery and disk-rebuilding procedures man need to be invoked more than once to complete recovery process, and hence off-line time will depend on the size and depth of the errors, from a few days to a week or more.

While most of data can be recovered, it may not always be possible. There may be cases where some of the vtv data cannot be recovered or in very rare circumstances all of the VLE data cannot be accessed/recovered, requiring some or all of the VLE data to be re-migrated.

VLE 1.4.0 has fixes for this specific integrity problem, both in terms of driver and OS updates. In addition there a number number of VLE and OS improvements and bug fixes in VL E 1.4.0 code. Customers are strongly urged to upgrade to VLE 1.4.0 to prevent possible data accessibility or loss issues.

The expected downtime to upgrade form 1.3.12 is 3 to 4 hours, but more time will be required if you are upgrading from an older version of VLE.

Please reference MOS Knowledge Document 1483386.1 for VLE Code Releases information.

This solution has no attachment