Asset ID: |
1-72-1338840.1 |
Update Date: | 2017-05-22 |
Keywords: | |
Solution Type
Problem Resolution Sure
Solution
1338840.1
:
HP LTO-3 - Frequent Tape Stuck Issue in SL8500 Library
Related Categories |
- PLA-Support>Sun Systems>TAPE>Tape Hardware>SN-TP: OEM Drive and Library
- _Old GCS Categories>Sun Microsystems>Storage - Tape>Drives - LTO
|
In this Document
Applies to:
HP LTO3 Tape Drive - Version Not Applicable and later
Information in this document applies to any platform.
Symptoms
Customer's SL8500 is using HP LTO3 FC drives.
Recently several drives randomly experienced media stuck issues.
Suggestion was to upgrade drive firmware and library code.
Customer wanted to know why upgrading firmware would reduce or fix media stuck issues.
Current HP drive f/w are M66S and L63S.
Cause
Most of the stuck media issues I see are due to mis-handled LTO cartridges. (See attached picture.) The cartridges get dropped which displaces the leader. This causes the plastic cartridge shell to separate and expand. The cartridge is then too fat to easily slide into the throat of the drive. It then gets stuck in the drive and can also cause robotic failures.
Upgrading your firmware levels can certainly help but I would document the tapes that are failing and check them. If you suspect this may be the problem, you will need to have the customer check all the tapes going into the library for this condition. Most tapes can be fixed by re-seating the leader pin.
As long as the drives have the latest code (which are EOL now so are pretty solid code wise if at the latest) and the library code is current, then the only thing we have seen cause issues is media handling.
Solution
We had a major issue a year or two back with stuck cartridges in HP LTO3 drives in two SL8500s on different locations (Same customer).
The problem turned out to be poor quality media.
(They began buying media from another source because it was much cheaper than Oracle media.)
Read write reliability was fine - the issues were mainly with the cartridge case quality - resulting in load/unload failures.
If different bots were involved at the site, suggest having the customer gather each of the broken tapes for inspection.
- Check for what is unique about them as opposed to those that did not stick.
- Note the brand and batch number (printed on the underside of the casing).
- If the cartridge memory CM data can be read, it will tell where/if the tapes were previously mounted.
- The backup application can often tell the same information and much more.
- Get the interior serial number of the cartridges.
If HP have overwritten the manufacturer field with their own brand we can trace the source back using the internal serial number.
Netbackup for example records the barcode, the manufacturer, and the internal serial number of every tape mounted successfully so on these sites you can gather a lot of this data without ever handling a tape.
The HP LT&T support ticket may tell you more on specific events..
The main clue is the problem started recently.
Firmware does not go bad.
So something changed on this site that led to increased stuck cartridges.
- Were new cartridges introduced?
- Were cartridges returned from from off site storage?
- Any change in the environment or procedures?
- Were Handbots replaced?
Let the customer know you want them to keep the backup application logs so that you can easily track tape movements in the event of any future stuck cartridges.
He might want to turn up logging verbosity till the case is closed.
If you do get a load failure grab a support ticket as soon as you can.
One other thought - Is the customer seeing tapes that are being "frozen" or "marked as full" due to being "write protected" when they are not write protected?
(Another symptom for this issue).
This is almost certainly not a a firmware issue so, as is often the case, you need to devise your own investigation plan.
That gets a whole lot easier if you can get the customer backup administrator to partner with you on the investigation.
Provided by Rob Tucker and Joe McNicholas
Attachments
This solution has no attachment