![]() | Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition | ||
|
|
![]() |
||||||||||||||||
Solution Type Problem Resolution Sure Solution 2100221.1 : T10000A/B/C/D - Append issues
In this Document
Applies to:Sun StorageTek T10000 Tape Drive - Version All Versions to All Versions [Release All Releases]Sun StorageTek T10000B Tape Drive - Version All Versions to All Versions [Release All Releases] StorageTek T10000C Tape Drive - Version All Versions to All Versions [Release All Releases] StorageTek T10000D Tape Drive - Version All Versions to All Versions [Release All Releases] Sun StorageTek T10000A Tape Drive - Version All Versions to All Versions [Release All Releases] Information in this document applies to any platform. SymptomsAppend issues on T10000 Tape Drives. 3975, 3656, 3679, 395B, and 37A4 are common FSCs for this issue. FSC395B FSC3975 FSC3656 FSC3679 FSC37A4 CauseTape drive that has a marginal write system. SolutionAppend type errors can occur if the tape is mounted in a drive and is told to append some data however when the drive tries to sync up on previously written data (so that it can write some new data behind it) the drive is unable to sync up on (cannot read) the previously written data. Troubleshooting the problem involves reviewing the tape drive event logs to see if this is a one time (or a small number of append errors) event on the drive. If you see many append errors across multiple tapes on a single drive then then you most likely have a defective drive. The drive is most likely having problems appending to data that it just wrote. If you only see a small number of append errors in the log for a single drive then you do not know if this drive is the problem You will need to identify the drive that wrote the previously written data to find the marginal writing drive. It is possible that the previous data was actually written by the same drive that cannot append. Sometimes this can occur on the same mount but we cannot assume that this is the case unless you see many append errors for the 1 drive. For a failure on 1 or 2 tapes is recommended to have the customer copy the data off of the tape and then re-use the tape vs. trying to identify the drive that originally wrote the data. In many cases the culprit drive took write perm errors and was already replaced. Troubleshooting Process If There Are Only A Few Append Errors In the Event Log: Only follow this process if it is necessary to identify the drive that wrote data that cannot be appended to. Obtain a set of logs from the drives and a dump from a couple of these tapes to start the troubleshooting process. Follow this process to obtain the needed dump: L2 Support can match the failures found in the logs with the MIR and RFID information in the dumps and try to determine what drive wrote the data that cannot be appended to. If L2 Support is unable to match things up from this dump then a forced dump is required from an actual append failure. To get this dump at the right time have the customer down the drive after the append failure so that a dump can be forced. (The dump needs to be triggered before the next tape is mounted)
Note: Released 3.65.103 code for T10KC and released 4.14.102 code for T10KD has additional information for read errors and append errors that will help to troubleshoot these error types. The drive code was changed to add the drive serial number of the drive that wrote the current mcf and the signature mcf for events. This will be added to the SPLAT tabs at some point. These 2 columns are the ones to use: They are in column BD and BE in a spreadsheet of the all_evl.csv file. They are to the right of the tape_alerts column. They will only be populated for read errors or append errors.
Attachments This solution has no attachment |
||||||||||||||||
|