| Hi,
You can create a little script that you can start as a daemon from
within /sbin/rc3.d/Sxxnsrd.
But, what is the benefit to "mount" automatically a tape in a device,
if you should STILL have to UN-MOUNT with the NSR software the tape
already present in the device. Maybe someone of engineering can confirm
or infirm that when NSR unmount a tape, it is writing a tape mark on it.
So, if you simply remove physically the tape from the device and with a
similar script you "un-mount" it from NSR, will the "un-mount" succeed
?
The core of this script should do the following:
Use the nsrmm command to mount the tape in the device when the device
is transitionning from NOTREADY to READY state. You should use the
command tur(8) (Test Unit Ready whith the argument -a b.t.l where
b=bus number, t=target number and l=logical unit number.) So, if your
tape is SCSI-ID 5 on the SCSI BUS 0, you should use "tur -a 0.5.0"
#!/bin/ksh
while :
do
NL=`tur -a 2.5.0 2>&1 | wc -l `
if [ "$NL" != 1 ]
then
NOTREADY=1
READY=0
else
READY=1
fi
if [ $READY = 1 -a $NOTREADY = 1 ]
then
nsrmm -m -f /dev/nrmt0h
NOTREADY=0
fi
sleep 10
done
Regards, Manu.
|
| I am very VERY uncomfortable with the idea of somebody changing
tapes without coordinating with NetWorker!
NetWorker always assumes that it knows what tape is in the drive
at any point in time, and that it knows where the tape is positioned.
If you go around and cause its assumptions to be invalid, you're asking
for problems. NetWorker in general attempts to validate its assumptions
by verifying the label of a tape before it starts writing, but there
may be windows in the logic which could allow a new tape to be substituted
without NetWorker realizing it...
I really don't think we want your customer to find these windows by having
their backups screwed up...
If your customer REALLY doesn't want their operators to have to deal with
NetWorker during the nightly backups, talk them into a jukebox.
Everybody will be MUCH happier!
Kevin
|