Sun Microsystems, Inc.  Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-1146537.1
Update Date:2011-04-19
Keywords:

Solution Type  Problem Resolution Sure

Solution  1146537.1 :   VSM--VTV written at the time of check0 results in permanent data check  


Related Items
  • Sun StorageTek VSM System
  •  
Related Categories
  • GCS>Sun Microsystems>Storage - Tape>Tape Virtualization
  •  




In this Document
  Symptoms
  Cause
  Solution


Oracle Confidential (PARTNER). Do not distribute to customers
Reason: FYI

Applies to:

Sun StorageTek VSM System - Version: 4 to 5C - Release: 4.0 to 5.0
Information in this document applies to any platform.

Symptoms

After any VTSS (VSM4 VSM5) warmboot, a VTV being written could appear to complete write job successfully, but later fail to be read successfully. Inability to read the affected VTV results in a Loss of Data. This problem was detected by VSM Engineering as part of an internal test and as of this writing, there has been one documented instance of a customer problem on a VSM4.

Cause

If a VTV has just completed writing the last page block (block x7CEE), which overflows into the next page, and the check0 warmboot occurs after the write completion status acknowledgement, but before the next page meta data is updated, the next write (block x7CEF) into the first block of the next page, will not properly reflect the offset into the next page. The customer data is correct, but the meta data directing the read did not acknowledge the page offset properly and directs the read to the wrong start byte location. The result is the data block on the VTV is not able to be read, i.e. returns permanent data check.
Note- That there is a very small window of failure. The warmboot must occur at the time that the last block of a page completed writing, for a write that will span into the next page.

Solution

Fixed with scn 46263 in EC released microcode D02.05.02.00. This fix corrects the next_block_offset page update before the prior block write signals completion and acknowledged by the host. So then if a warmboot occurs after the host ack (acknowledgement) , the meta data update will be shown to be complete and there is no inconsistency with the new data writes (offset) after the warmboot completes.


Attachments
This solution has no attachment
  Copyright © 2011 Sun Microsystems, Inc.  All rights reserved.
 Feedback