scan

[noazara]

[root]$ cat /proc/scsi/scsi

Attached devices:

Host: scsi0 Channel: 00 Id: 06 Lun: 00

  Vendor: CERTANCE Model: ULTRIUM 2        Rev: 1000

  Type:   Sequential-Access                ANSI SCSI revision: 03

Host: scsi0 Channel: 00 Id: 06 Lun: 01

  Vendor: QUANTUM  Model: UHDL             Rev: 0051

  Type:   Medium Changer                   ANSI SCSI revision: 02

[@root~]$ cd /usr/openv/volmgr/bin

[@rootbin]$ sudo ./scan

                 :

************************************************************

*********************** SDT_TAPE    ************************

*********************** SDT_CHANGER ************************

************************************************************

[                @rootbin]$ pwd

/usr/openv/volmgr/bin

[                @rootbin]$ uname -an

Linux root2

[                @rootbin]$ '

Please let me know why NBU is unable to see the devicees via OS?

cat /proc /scsi/scsi is giving the o/p.Where is the problem here then.OS is seeing the devices as per the SCSI o/p

[mph999 · Accepted solution]

This is nothing to do with NBU. scan is not really a NBU command (yes I know it is supplied with NBU) - it simply sends a scsi inquiry command to each device configured in the OS. What is happening, is simply that the devices are not responding to the scsi inquiry command sent to them. Although rare, it is possible that even though the devices are in /proc/scsi/scsi they are not fully working at the OS level, I would remove them from the OS and readd them, see if that clears the issue. If that does not work, need to dig a bit more - perhaps try this : mt -f status This is an os command, does this return anything ? As a matter of interest, what s the hstory of this, has it ever worrked ? If mt works, but scan doesn't I suspect there is something that s either stopping / corrupting the scsi inquiry command sent, or, is stopping the reply. I've seen a very similar issue on Solaris - drives worked perfectly in the OS, mt worked, tar worked but NBU couldn't mount the tape. Turned out the HBA firware was stopping the drive sending back the response to a scsi test-unit-ready command, 100% nothing to do with NBU. If still no luck you will need to look closer at the HBAs, HBA drivers, HBA firmware, Possibility of faulty drives (not likely of more than one is having an issue), OS tape drivers or OS patch. Unfortunately, there is nothing that can be done in NBU to fix this, and there are no options or adjustments that can be made to the scan command. There is /usr/openv/volmgr/bin//scsi_command -d - this is efectivly the same as scan, it just sends a scsi command nothing more. It does not use any nbu code, is not a nbu command and in fact will work with NBU stopped. You need to forget NBU, it has nothing to do with this issue. If you decide to contact your hardware support you need to explain to them that the device(s) are not responding to a scsi inquiry command. Martin