Constant Unlabeling of Tapes in Networker 8.2.4.12

If the tape has been used already, there has a label been written. The tapes are not unlabeled. Of course, if there is a problem reading tapes, then the backup software may recognize it as unlabeled.

As you say, there is a 50/50 chance that it will run successfully. So I expect that the installation will work in general. However, such may indicate that the tape drive's R/W head needs cleaning. This is what I would try first. If this does not help, you should try another tape drive, if such exists.

And please be careful and state the facts exactly. It is important to differentiate ...

  -  whether you load/insert a tape

  -  whether you 'only' label a tape

  -  whether you label and mount a tape

 

Hello Bingo,

I tried cleaning the tape drives R/W head and no luck. I actually had the vendor take a look at the juke box and they stated that everything was working correctly. Any other ideas as to where I could look? I appreciate the help.

The problem is that your error does not always occur - it is a temporary issue. As such it is hard to investigate.

Fact is that a tape cannot become "unlabeled" once a label has been created. Since then, the tape has been written and this label cannot be physically deleted. There are only very (40+ year) 1/2" reel tape drives where this is possible (and NW supported those as well) but I am pretty sure that this is not the case in your environment     I guess that you use some kind of LTO hardware.

So we have to find out why the tape label cannot be read. And there are a bunch of possible reasons:

  -  the tape itself has been worn

  -  the tape drive is defective

  -  the compatibility of tape and tape drive

  -  there might be an issue with cabling, termination, controller, driver etc.

But what else shall I mention as you did not specify anything else but "only 50% of all attempts are successful". At least it would be good to know about your environment and what has recently changed - especially with respect to hardware changes and/or upgrades.

Do not blame the software - it will just forward a hardware issue. But to investigate this more thoroughly, you could test the hardware with other (native OS) software ... an compatible media which can be overwritten.

 

As Bingo.1 states, a tape cannot simply be unlabeled, especially as another inventory might show them up as being labeled still. So then it still was labelled, but the label wasn't able to be read.

Hence it is very likely hardware error, if not the tape drives, then very likely the tapes themselves. But could also be the the SAN connection or on NW storage node end wrg to drivers. Something causing bus resets is also very cumbersome.

Depending on the library in question, it might also have information of how many times a specific tape has been mounted. Even though "mminfo -m" states a column "mounts" according to the mminfo manpage it is "the number of times the read-label operation has been performed on the volume (not the count of explicit mounts)".

So the statistics from a tape library that supports that has the option to extract that information, might be a good way to determine to see if the tapes affected are possibly the ones used the most (not only mounts but also data written and read). Also the same option might have information about encountered hardware errors of tape drives, to be able to see which drive(s) acted up the most, to see if there is a correlation with the tape drives that appear to act up when performing the inventory using NW.

For IBM tapelibraries we were able to create some pivot tables. Even looked into tape system reporter application years ago supposed to collect data about the statistics of tape libraries.

If no such options exist, it is a bit trial&error if the supplier states nothing is the matter, as you'd have to more or less prove where things go wrong.

If you are using multiple tapedrives, test for example multiple inventory runs using one and the same tape drive only, instead of using multiple tape drives to do so.

You can also do so even without mounting the tapes by scripting it to load-no-mount a tape in a drive and then trying to read the label? I used that often, for example to test if a device file for a NW storage node was (still) correct after certain maintenance, like on the library or on the san or anything really. Then if a label could not be read, you wouldn't have to go through resetting device on NW end as a tape was not asked to be mounted anyways.

So setting up a script that would loop through the slots to have tapes loaded from a specific slot into a specific drive (that is a lowercase "L" and not an uppercase "i" in the "nsrjb -lnv")) or drives and then reading the label using things like and once read (or not) unmount the tape again in its original slot:

$ nsrjb -lnv -S1 -f "rd=xxxxx:/dev/rmt1"
$ nsrmm -pv -f "rd=xxxxx:/dev/rmt1"
$ nsrjb -uv -S1 -f "rd=xxxxx:/dev/rmt1"

You could easily have it looping over and over again for a given slot range for a specific drive, trying to see if it goes wrong with specific tapes or drives.

I for one am happy we have almost no tape libraries left at all, having gone all-in on DataDomain deduplication appliances. No longer any daily issues with tapes, drives and libraries or device file changes.