Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

No tape Label found

Status
Not open for further replies.

Smerlap

MIS
Aug 31, 2006
8
FR
Hello,

After adding a new SDLT320 drive in jukebox L700, networker load a volume in this drive, but label verification fails on this error :

nsrd: /dev/nst4 Verify label operation in progress
nsrmmd #6: tape_bsf bsf failed: drive status is The drive is not ready and the reason is not known
nsrd: media warning: /dev/nst4 moving: tape_bsf bsf failed: drive status is The drive is not ready and the reason is not known
nsrd: media warning: /dev/nst4 reading: no tape label found
nsrmmgd: RAP error: Invalid resource data.
nsrmmgd: Cannot update operation status resource (instance2)

The problem is the same with all tapes. Errors in /var/log/messages are the same. Jbverify show any error. mt -f status gives no error. I try to increase "load sleep" to 120s, but without success.

Firmware of this drive is the only difference with others drives (>)
Device block size is configure on "variable"

Networker software is 7.3.1, running on Linux X86 - RedHat AS4.

Do you have idee about this ?
Many thanks
 
I guess you simply 'talk' to another drive than the one you inserted the media.

Verify your settings with inquire and re-install the jukebox, if necessary.
 
The question is whether NetWorker is actually reading the tape from the drive that the tape is loaded in. In other words, if NetWorker is requesting that a tape is loaded into /dev/nst4, does the robotic arm actually load the tape into the drive that /dev/nst4 is defined for?

This all falls under the topic of verifying the drive order.

Simple test. Physically load a tape into the first drive, then use "mt -f (drive) status" to see if the tape is loaded.

Another command that can be used for testing is scanner -v (drive). The advantage of using scanner is that it will also verify if there is a tape label on the drive.

If drive ordering is correct, then I might suggest asking the the NetWorker 7.3.2 jumbo build 11. Though it is not officially released, you can request it from support.
 
You can of course also use mt or any other command for all your drives toi determine which device has been loaded.
 
Many thanks for your answer,

Here is the result of scanner (no error with mt -f status) :

root@usu>nsrjb -lnv -S 677 -f /dev/nst4
setting verbosity level to `1'
nsrjb: Info: Loading volume `-' from slot `677' into device `/dev/nst4'.

root@usu>scanner -v /dev/nst4
scanner: /dev/nst4: opened for reading
scanner: /dev/nst4: rewinding
scanner: Rewinding done
scanner: Reading the label...
scanner: Reading the label done
scanner: SYSTEM error: Tape label read for volume ? in pool ?, is not recognised by Networker: Input/output error
scanner: SYSTEM error: Tape label read for volume ? in pool ?, is not recognised by Networker: Input/output error
scanner: scanning for valid records...
scanner: read: -1 bytes : Input/output error
scanner: Cannot continue
scanner: No valid tape records found

We try to write with Tar command on /dev/nst4: no problem.
The same volume load

I try to delete the jukebox and run jbconfig.

Thanks a lot
 
Did you use tar before scanner? - in this case i assume NW simply claims that it does not find a NW label.

This of course is obvious. A backup software usually just identifies its own labels.
 
The problem is not with the jukebox. It is a problem with the tape drive, so running jbconfig won't help you. The only exception would be if you configured the SDLT320 drive as something else in NetWorker.

Do you have the same problem if you use a new tape?

Do you have the same problem when you use any tape?

The "tape_bsf bsf failed" error implies that a rewind to a certain file position on the tape failed. This is normal if this is on a new tape, but it is not normal if there is previously written data on the tape.

If you have other tape drives, does the same problem happen if you load the same tape on the other drives? Are the other tape drives of the same make and model?

Lastly... check the stinit.def file and verify that you have the proper settings for your tape drives. These settings you can get from your tape drive vendor.

Good luck.
 
With a new tape, networker is unable to label it.
It's the same error with any tapes.

All drives in L700 jukebox are Quantum SDLT320.

Just a strange thing : last week mt -f status on the drive give :

root@usu>mt -f /dev/nst4 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x48 (Quantum SDLT220).
Soft error count since last status=0
General status bits on (9010000):
EOD ONLINE IM_REP_EN
root@usu>

This morning, mt -f status give :
root@usu>mt -f /dev/nst4 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x49 (Quantum SDLT320).
Soft error count since last status=0
General status bits on (49018000):
BOT EOD ONLINE IM_REP_EN CLN
root@usu>

So last week, I had a SDLT220, this week I have a SDLT320.

Perhaps if I switch this drive with another one, I can have more informations.




 
2 other drives failed with the same error message.
But the dmesg from Linux gives some errors like : st3:
Error with sense data: Info fld=0x0, Current st3: sense key Medium Error
Additional sense: Write error
st3: Error on write filemark...

OS can't speak correctly with drive.
 
IF the OS can not handle the drive, how can any other software using standard drivers use it?
 
I have a simular problem after upgrading Networker 6.1.4 to 7.3.2 on an AIX system. When we try to label a tape we got tape_bsf errors. I have an open request at EMC but no solution untill now. Where you able to solve this problem?
 
In NW 7.0 Legato intoduced another mechanism to talk to the devices - CDI. This could be the problem.

Try to change the CDI setting for the device to "not used".
 
Hello,

No problem, CDI is disabled. We have mount and unmount 40 different tapes from the librarie, and the 41ers was read without problem ! All this tapes were writing when the Networker server was running on Solaris.

Now all seems to be running well but we always have those messages in the dmesg (not in /var/adm/messages)

st5: Block limits 4 - 16777212 bytes.
st1: Block limits 4 - 16777212 bytes.
st3: Block limits 4 - 16777212 bytes.
st2: Block limits 4 - 16777212 bytes.
st4: Block limits 4 - 16777212 bytes.
st0: Block limits 4 - 16777212 bytes.
st4: Error with sense data: Info fld=0x8000, Current st4: sense key Medium Error
Additional sense: Unrecovered read error
st4: Error with sense data: Info fld=0x20000, Current st4: sense key Medium Error
Additional sense: Unrecovered read error
st4: Error with sense data: Info fld=0x8000, Current st4: sense key Medium Error
Additional sense: Unrecovered read error
Losing some ticks... checking if CPU frequency changed.
st2: Failed to read 131072 byte block with 32768 byte transfer.
st1: Failed to read 131072 byte block with 32768 byte transfer.
device eth0 entered promiscuous mode
device eth1 entered promiscuous mode
device eth2 entered promiscuous mode
device eth3 entered promiscuous mode
device bond0 entered promiscuous mode
device eth0 left promiscuous mode
device eth1 left promiscuous mode
device eth2 left promiscuous mode
device eth3 left promiscuous mode
device bond0 left promiscuous mode
st2: Failed to read 131072 byte block with 32768 byte transfer.
st4: Failed to read 131072 byte block with 32768 byte transfer.
st2: Failed to read 131072 byte block with 32768 byte transfer.
st2: Failed to read 131072 byte block with 32768 byte transfer.
st1: Failed to read 131072 byte block with 32768 byte transfer.
st1: Failed to read 131072 byte block with 32768 byte transfer.
st1: Failed to read 131072 byte block with 32768 byte transfer.
nsrjobd[24217] general protection rip:34e626898b rsp:7fbfffe220 error:0
nsrjobd[4773]: segfault at 0000005f828411e0 rip 00000034e600a6af rsp 0000000042285950 error 6
nsrjobd[4772]: segfault at 0000005f828411e0 rip 00000034e600a6af rsp 00000000418849b0 error 6
st1: Failed to read 131072 byte block with 32768 byte transfer.
st1: Failed to read 131072 byte block with 32768 byte transfer.
st1: Failed to read 131072 byte block with 32768 byte transfer.
st1: Failed to read 131072 byte block with 32768 byte transfer.
st1: Failed to read 131072 byte block with 32768 byte transfer.
 
Verify your blocksizes. It seems that you run on 32kB only but have tapes written with 128kB blocks.

Also, do not forget that jumbo patch 11 has been released yesterday. You may want to update.
 
Thanks, The device block size is set to variable (0).
I don't know how to set block size in Linux, because the stinit.def is not loading in the system. Do you have an idee ?
 
It is done via indirectly by selecting the device type. Only if you have received media from another side, you might need to do this by setting the environment variable, NSR_DEV_BLOCK_SIZE_devicetype=blocksize .

For example, set NSR_DEV_BLOCK_SIZE_8MM_AIT-2=32
 
Finally, the networker solution will be re-install, because too many problems : one month ago, when the administrator move the networker server from Tru64 to Linux OS, he just copy the nsr directory to the new machine !

Many thanks
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top