Basics – Bypassing NetWorker for media movement

Sometimes NetWorker may not want to cooperate when it comes to moving media in and out of drives, or around in a tape library. While nsrjb -n will do the trick for some media load operations where you don’t want to mount media, it’s not always available. Sometimes you will need to do a media move operation without NetWorker – either in situations where NetWorker isn’t running, or at times when NetWorker is disagreeing with the output of sjirdtag.

In these cases, you want to work with sjimm.

The usage for sjimm is:

[root@tara ~]# sjimm
1642:sjimm: usage: sjimm jukebox {drive|slot|inlt|mt} src {drive|slot|inlt|mt} dst

In this case, ‘jukebox’ will be the x.y.z component of the SCSI device ID as output from inquire (or as determined by checking the control port field for the jukebox.)

For instance, on my lab system, inquire shows me:

[root@tara ~]# inquire -l | grep Autochanger
scsidev@0.0.0:SPECTRA PYTHON          5500|Autochanger (Jukebox), /dev/sg6

So I know then that the jukebox component of my sjimm command will be 0.0.0.

So say I wanted to move the tape in slot 23 into the first drive in my autochanger. I’d use the command:

[root@tara ~]# sjimm 0.0.0 slot 23 drive 1

Note though that this doesn’t mount the tape. If I then run nsrjb, for my drive area I see:

drive 1 (/dev/nst0) slot   :   
drive 2 (/dev/nst1) slot   :   
drive 3 (/dev/nst2) slot   :   
drive 4 (/dev/nst3) slot   :   
drive 5 (/dev/nst4) slot   :   
drive 6 (/dev/nst5) slot   :

Note too that I didn’t give the drive to load the tape into as a operating system device, but instead a device number as per the autochanger’s definition. (I’ll get to tracing that in a minute.)

I can verify that there is a tape in the given drive at this point by running the command:

[root@tara ~]# nsrmm -p -f /dev/nst0
Verified LTO Ultrium-4 tape 800823L4 on /dev/nst0

When you’re done with the tape, you can then move it back:

[root@tara ~]# sjimm 0.0.0 drive 1 slot 23

Note that depending on the drive type, it may be necessary before issuing the above command to issue the mt command to take the media “offline”, which usually issues an eject command to the drive – e.g.,:

[root@tara ~]# mt -f /dev/nst0 rewoff

Other than that, there’s actually not a lot to sjimm. You can move tapes from slots to drives, slots to CAP slots, drives to slots, slots to slots, etc.

However, I did mention that I’d help you work out what drive number corresponds to what operating system device. Obviously if you’ve got the library configured, you can just use nsrjb’s output to see see the autochanger device <-> OS device path mapping. If you don’t yet have a tape library configured in NetWorker, or the issue is determining which drive is currently mapped to which path (after say, a tape drive replacement), you need to do a little more digging.

So, in this case you’d run sjisn – which is designed to report serial numbers and device details for tape library components. Like sjimm, sjisn takes the control port of the tape library we want to communicate with – e.g.:

[root@tara ~]# sjisn 0.0.0
Serial Number data for 0.0.0 (SPECTRA  PYTHON          ):

Library:

Serial Number: XYZZY

SCSI-3 Device Identifiers:

ATNN=SPECTRA PYTHON          XYZZY

WWNN=11223344ABCDEF00

Drive at element address 1:

SCSI-3 Device Identifiers:                         ATNN=ZF7584364

Drive at element address 2:

SCSI-3 Device Identifiers:

ATNN=ZF7584366

Drive at element address 3:

SCSI-3 Device Identifiers:

ATNN=ZF7584368

Drive at element address 4:

SCSI-3 Device Identifiers:

ATNN=ZF7584370

Drive at element address 5:

SCSI-3 Device Identifiers:

ATNN=ZF7584372

Drive at element address 6:

SCSI-3 Device Identifiers:

ATNN=ZF7584374

The number given in the "Drive at element address" line for each drive represents, literally, the drive number according to the tape library itself. I.e., when it refers to drive 1, it means the drive with serial number ZF7584364.
Moving on, we can then run inquire -l to provide the device details so as to align internal library drive numbers to operating system paths, cross-referencing by the serial numbers (or WWNs when using a fibre-channel tape library).  In this case, I'll just show the details for two of the tape drives:
scsidev@0.3.0:IBM     ULT3580-TD4     5500|Tape, /dev/nst2
                                           S/N:    ZF7584368
                                           ATNN=IBM     ULT3580-TD4     ZF7584368
                                           WWNN=11223344ABCDEF03
scsidev@0.4.0:IBM     ULT3580-TD4     5500|Tape, /dev/nst3
                                           S/N:    ZF7584370
                                           ATNN=IBM     ULT3580-TD4     ZF7584370
                                           WWNN=11223344ABCDEF04
So, you can see from the above that we can map the drives as follows:

The drive known to the OS as /dev/nst2, which has a serial number of ZF7584368 maps to the library device number 3.
The drive known to the OS as /dev/nst3, which has a serial number of ZF7584370 maps to the library device number 4.

So this would give us the drive numbers to use in sjimm if we needed to move tapes in or out of those drives without using NetWorker's NMC or nsrjb.
As a side-note, that's also how you'd go about identifying the correct device order for a manual jbconfig operation when the library device order is out of sync with the operating system devices – cross-checking via sjisn and inquire.
Did you like this post? Please share it.
Facebook
Twitter
Reddit
Email
Print
LinkedIn
Tumblr
Pinterest
Pocket
WhatsApp
Like this:
Like Loading...


Related posts:

Basics – Peeking inside your jukebox without leaving your desk
Basics – Commands you should know
Basics – Jobkill goes interactive
Basics – Understanding NetWorker Architecture