I ran the nsrjb -HEvv command and after this command completed I could see the tapes re-appear in the Slot-6 and Slot-19.
I was lucky here as I managed to clean the drive that was shouting for cleaning
However my backup still fails and I see timed out errors and I suspect the SCSI here because when I happened to check the eventvwr I see a log which reads as below:
" The device, \Device\Scsi\adpu160m1, did not respond within the timeout period "
I think this might have something to do here as I see this logged everytime the backup fails. It may be because of a slowly performing device is what I feel or may be poor cabling causing this any thoughts on this as how this bad performing device can be identified.
Failing backup is another story OK, first to explain what happened. nsrjb -HE does element status reset meaning you send init to library and library will do new inventory and application will pick it up. It is possible these tapes were moved around without NW knowing about (like manual import) or something else may happened leading to split brain.
As far as the error goes, yes, you get an error from driver at OS level which says it is getting timeout communicating with device. I have seen few of those in the past and I absolutely hated them as that's pretty much everything you will get on Windows. As to what it is, well, you have broad selection here: cable, HBA/SCSI card, faulty driver, SAN, you name it. I checked web and 132T seems to be some baby toy which might even have one drive. Is this correct? In such case, most likely robotics and drive go over the same pipe which may explain split brain from before. I guess what you could do easily is to:
- check Windows even logs for any additional clue (most likely none)
- make sure RSM is disabled (most likely it is)
- check from display panel of library logs for both drive and library to see if any error has been reported
- if using SAN, check switch logs and check error count on port utilized by this equipment... you may wish to write it down and try to force the error again to see if counter goes up
ble1
4 Operator
•
14.4K Posts
1
December 2nd, 2011 08:00
Run nsrjb to obtain library view as seen by NW.
Run nsrjb -V to obtain control port.
Run sjirdtag to obtain library view as seen by library.
Compare these two.
If there is difference, run nsrjb -HvE and then inventory.
shanks619
3 Posts
0
December 3rd, 2011 08:00
Thanks Hrvoje,
I ran the nsrjb -HEvv command and after this command completed I could see the tapes re-appear in the Slot-6 and Slot-19.
I was lucky here as I managed to clean the drive that was shouting for cleaning
However my backup still fails and I see timed out errors and I suspect the SCSI here because when I happened to check the eventvwr I see a log which reads as below:
" The device, \Device\Scsi\adpu160m1, did not respond within the timeout period "
I think this might have something to do here as I see this logged everytime the backup fails. It may be because of a slowly performing device is what I feel or may be poor cabling causing this any thoughts on this as how this bad performing device can be identified.
ble1
4 Operator
•
14.4K Posts
0
December 4th, 2011 22:00
Failing backup is another story
OK, first to explain what happened. nsrjb -HE does element status reset meaning you send init to library and library will do new inventory and application will pick it up. It is possible these tapes were moved around without NW knowing about (like manual import) or something else may happened leading to split brain.
As far as the error goes, yes, you get an error from driver at OS level which says it is getting timeout communicating with device. I have seen few of those in the past and I absolutely hated them as that's pretty much everything you will get on Windows. As to what it is, well, you have broad selection here: cable, HBA/SCSI card, faulty driver, SAN, you name it. I checked web and 132T seems to be some baby toy which might even have one drive. Is this correct? In such case, most likely robotics and drive go over the same pipe which may explain split brain from before. I guess what you could do easily is to:
- check Windows even logs for any additional clue (most likely none)
- make sure RSM is disabled (most likely it is)
- check from display panel of library logs for both drive and library to see if any error has been reported
- if using SAN, check switch logs and check error count on port utilized by this equipment... you may wish to write it down and try to force the error again to see if counter goes up