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.0Serial 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.
