Sun StorageTek Virtual Tape Control Software (VTCS)
 
Sun StorageTek Virtual Tape Control Software (VTCS) for VSM Fujitsu MSP
 
Sun Virtual Library Extension (VLE)
 

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

In this Document

Symptoms

Changes

Cause

Solution

Applies to:

Symptoms

VTCS audit of VLE can cause one or more copies of a VTV to become unlinked in the CDS.
Essentially by unlinking a VTV copy in the CDS, that VTV copy is no longer available to the customer.

• Audit of VLE could result in as few as one copy of VTV data remaining on VLE depending on the customer configuration and VTCS policy for managing data stored on VLE.
• For example: VLE1 and VLE2 are connected via a copy link. VTCS policy specifies that a copy of each VTV will be stored on both VLE1 and VLE2.

1. 1. VTV is migrated from VTSS to VLE1 (Copy 1).
   2. Per policy, VTCS then migrates a second copy to VLE2; the copy is performed via VLE-to-VLE copy operation. (Copy 2).
   3. VTCS currently shows both valid copies in the CDS; one on each VLE; per policy.
   4. A VTCS Audit of VLE2 is performed.  VTCS examines the metadata for the VTV on VLE2 and determines it is the same as for the VTV stored on VLE1.  VTCS then unlinks the VTV copy on VLE2 leaving only one copy of the VTV on VLE1 according to the CDS.
   5. The unlinked VTV data will not be recovered by VTCS automatically and a second copy of data would only be re-written by re-migrating the VTV or a Reconcile be performed.  

Changes

Exposure

-          All VLE systems using VLE 1.1 or VLE 1.2 AND are configured to utilize VLE-to-VLE copy operations.  If VLE-to-VLE copy is not used there is no exposure.

-          VTV data stored on VLE is NOT exposed if:

• • For multiple VLEs, there are no copy links connecting two (or more) VLE systems together – In other words, the only data path connections to the VLE(s) are from the VTSS (VSM5 or VSM6).
  • For a single VLE, there is only a single copy (and not multiple copies) of a VTV on the VLE.

-          VTVs that are stored on RTDs or in the VTSS buffer are not exposed to this issue.

Cause

VLE microcode issue relating to VTV metadata stored on VLE during VLE-to-VLE copy operations.

• When VLE-to-VLE copy is executed, the VTV metadata for the second copy is not updated appropriately.  Instead, the metadata from the original VLE copy is used for the second copy.
• VTVs stored via VLE-to-VLE copy operations are valid data copies.  Until a VTCS Audit is performed, the CDS recognizes all copies of a VTV.  The issue is that VTCS when reading VTV metadata during Audit, will believe both copies are the same copy of the data and will unlink one copy of the VTV.

Solution

Resolution (a two step process)

Step 1:

-          Upgrade to VLE 1.3 code OR

-          Install VLE 1.2.16 patch A4 – A fix for the metadata issue has been implemented in this patch.

-          NOTES:

• • There is no patch available for VLE 1.1.  If you are running VLE 1.1 code then upgrade to VLE 1.3.12 code.   
  • Subsequent to installing 1.3 or 1.2 patch A4, VTV metadata for all new VLE-to-VLE copy operations will be stored correctly
  • VTV metadata is updated via normal production operations due to deletes, scratches, recalls, and migrates.

Step 2:

-          Metadata created prior to the code upgrade or patch install can be manually updated by performing the following:

• • Drain/Eject VMVCs with VTVs containing incorrect metadata.

This solution has no attachment