Hmmm...could this be a SCSI reserve/release issue? Once you have
successfully mounted the tape on a DSN then try to mount on the server and
get a failure can you try running:
nsrjb -l -n -S <slot> -f /dev/nst0
which will load a tape from your chosen slot into your tape drive -without-
trying to mount the tape in NetWorker. You can use this to load a tape then
access it through the command line i.e.
mt -f /dev/nst0 status
mt -f /dev/nst0 fsf 2
If you have a blank tape you could even try writing to the tape:
tar cvf /dev/nst0 /home
to prove that the tape is write accessible. This will show that NetWorker
can successfully talk to the library and get it to load a tape, but will
probably show that the operating system isn't allowed to access the tape
once loaded. If this is the case then it could be that your Win2k3 DSN is
holding onto the drive.
Cheers
Mark
> Grrr...
>
> Well, I reran the persistent bindings cript given to me by Qlogic. It
> updated modules.conf with the same info already there. I remade the
> bootimage anyways and rebooted - and was able to mount a tape. So I
> unmounted it, and tried via one of the DSNs that share it - and got the
> DRIVE_CARTRIDGE_FAULT again - and then started getting it from the Linux
> box as well.
>
> So, I deleted the jukebox and drives, and recreated them again - and the
> same exact thing happened. Was able to mount a tape once on the Linux
> box, but not from the DSNs, and then couldn't mount on the Linux box again.
>
> I can't win..
>
> Brian O'Neill wrote:
>> I am aware of the "persistent binding" issue, but no one (not here, but
>> on the SAN side) has been able to satisfactorily explain what needs to
>> be done on the Linux side. The HBA vendor had a script to set the
>> persistent bindings, but it seems to have only cared about the Vault
>> itself - it doesn't seem to deal with the tape drives (which do not have
>> WWPNs, just WWNNs). If anyone has examples I can follow, I'd appreciate it.
>>
>> This does not appear to be the case here. /dev/nst0 still works fine,
>> but the drive that was replaced is the one with the issue. I can use
>> "mt" to communicate with the drive, but Networker seems to detect a
>> fault. The only thing I haven't tried to do yet is do some manual
>> operations with the tape drive outside of Networker (I have to have
>> someone do the manual operations as I am remote...)
>>
>>
>> Riaan Louwrens wrote:
>>
>>> Brian,
>>>
>>> What I see on a semi-regular basis is that drives that are attached to
>>> the seem to "change" their scsi path & thus drive ordering.
>>>
>>> I.e. the SAN doesnt apply "persistant binding" of the addresses. So
>>> when the operating system comes up it assigns a "new" device handle to
>>> them as they are discovered. (this is specific to Windows - but I am
>>> sure Linux / Unix works on a similar principle (i.e. /dev/rmt/ocbn
>>> doesnt actually refer to "drive 1" in your library anymore)).
>>>
>>> The way I test for it is (unfortunately a cumbersome route - but it
>>> works) to delete my libraries, create manual devices and then manually
>>> load tapes into each of them (note the tape labels) then to mount the
>>> tape in drive1 and see what labels comes up (do this for each of the
>>> drives).
>>>
>>> Then you can re-create your library accordingly.
>>>
>>> If your path to the autochanger is the same you should be able to use
>>> JBEDIT (7.x) to modify the paths to the drives.
>>>
>>> One needs to ensure that the SAN has "persistant binding" of all the
>>> devices and then soemthign I have found to help (from Windows again -
>>> sorry) is to make sure that the scsi cards with lower adresses are on
>>> lower numbered PCI slots in yoru system (i.e. they get picked up first
>>> and get assigned device handles first) ...
>>>
>>> Apologies if I have gone on a tangent for something you already know
>>> ... But this is where I have seen similar messages before.
>>>
>>> Regards,
>>> Riaan
>>>
>>>
>>>
>>
>> --
>> Note: To sign off this list, send a "signoff networker" command via email
>> to listserv AT listserv.temple DOT edu or visit the list's Web site at
>> http://listserv.temple.edu/archives/networker.html where you can
>> also view and post messages to the list. Questions regarding this list
>> should be sent to stan AT temple DOT edu
>> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listserv.temple DOT edu or visit the list's Web site at
> http://listserv.temple.edu/archives/networker.html where you can
> also view and post messages to the list. Questions regarding this list
> should be sent to stan AT temple DOT edu
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
