Disk/tape conflict?

[Dave Chamberlin]

I am confused about my disk system. I have several disks with hardware paths:
10/0.3.0 through 10/0.11.0 . The disk u05 is at 10/0.9.0 which should
mean that is is at SCSI address 9 on this FW controller. I have a DLT tape that
has been powered off since I have been here (a couple of months) and I wished
to use it for some backups. I powered it on and rebooted the system. The DLT
hardware path from ioscan was 10/8.5.0 . The tape worked fine for my backups
but the system "lost" my u05 disk which was now reported as "unused" in SAM.
I figured that it must be some kind of SCSI conflict and powered off the DLT
and rebooted the system, and u05 was back. I don't understand how the two
devices conflicted with different addresses. Can someone explain what is going
on? I would still like to use the DLT...

Thanks

[CHRIS_ANORUO]

Hi,

Change the jumper settings on the DLT tape drive, power it on and then power on the system to see the new changes.

Cheers!

[Patrick Wessel]

I disagree with Chris. This can't be a SCSI ID conflict because the disks are connected to the hardware path 10/0 and the DLT to 10/8. This paths have no physical connections accept, that thy are both located on the Core IO card.
Understanding SCSI is more an art than a science. I assume it's more a termination issue. Check all the small things like right termination (at both ends of the bus, nothing more, nothing less), term power.

Are the disk u05 and DLT connected to the same power line? Or is there anything else that this two devices have in common?

If the DLT is connected to the same bus (in other words the ioscan information you posted was misleading) it's obvious that it doesn't work. A DLT needs a dedicated bus. You can't operate it with a bunch of disks on the same channel.

[Michael Lampi]

I disagree with Patrick on two points. SCSI is not an art; it is definitely a science. One might have to do a bit of research to determine why a given solution does not work when it should, and vice versa, but there is no magic to it.

Some people have an intuitive way of coming to solutions, so they might be considered SCSI artists, but in the end it is definitely a science.

Secondly, the only reason a DLT drive should not be on the same SCSI bus as disk drives is when you want to have the highest possible performance when copying from those same disk drives to the DLT, and vice versa. Given the typically fragmented layout of data on disk drives, the FWD SCSI bus can get quite busy with disk traffic. This does not leave much headroom for the additional traffic added by transfering data to and from the DLT drive. If the disk drives need to wait for the tape drive to source or to sink data, then disk throughput suffers.

Likewise, if the tape drive needs to wait for the disk drives to source or sink data, then it might have to stop tape movement (streaming), which can dramatically affect tape throughput.

Otherwise, assuming that the SCSI ID's of all the devices are unique, then there is no electrical reason beyond overall SCSI cable length preventing you from connecting any desired mix of FWD disk drives and FWD DLT drives on one FWD SCSI bus.

I'd try rerunning ioscan with the DLT turned off to verify the hardware paths of all your devices. Perhaps you have a logical volume that uses two disk drives, one at the same address as the DLT and the other using 10/0/9 which, when combined, produce the u05 disk volume. So, when the DLT is turned on, it might conflict with the other volume of the set thus preventing u05 from mounting.

Another possibility is that the 10/0/9 drive might have been turned off when you booted with the DLT turned on. Not likely, but possible.

Still another possibility is that the 10/0/9 drive is encountering a race condition resulting from the system SCSI bus resets that occur during boot. It might be taking a long time passing its self tests so when the system tries to mount it, it fails. If you power on the DLT, boot the system, note whether or not u05 is available. If it is not available, try mounting u05 manually.

[Dave Chamberlin]

The DLT and the disk are different paths. I have physically traced the cables. The
only commonality is that they are both on the core IO card (k200) . The disks are
on the connector labeled F/ W SCSI (x/0) and it is terminated on the disk array
that it is connected to. The DLT is on the connector labeled "Optional I/O (x/8)".
The DLT has a termination connector on it as well. The DLT has a thumbwheel
switch set to ID=5. I did not save a copy of the ioscan for the disks when the
tape was connected, but the ioscan from the tape indicated c2t5d0, and the
current ioscan for disks gives c0t9d0 for the disk. Any other ideas?

[Patrick Wallek]

When you are accessing the DLT drive you are using /dev/rmt/c2t5d0 and NOT /dev/dsk/c2t5d0?

Do the correct /dev/rmt devices files exist for the DLT drive and do they exist ONLY in /dev/rmt and not in both /dev/rmt and /dev/dsk or /dev/rdsk?

[Patrick Wessel]

Dave,

Let's start to face the problem more structured.
When you write you lost the disk, what does that mean exactly?
- Is the disk still visible in ioscan?
- Is the disk mounted?
- Is u05 a logical voume or a volume group?
- What does a vgdisplay or a lvdisplay return?

Sorry for asking those basic questions, but I try to make me precise picture of your situation.

[Dave Chamberlin]

As it turns out, I turned on the tape drive, did an ioscan -fnC tape, and there it was
again, but this time there were no problems with my disks. Still there after a reboot
so I have to believe that the problem was not related to the tape, but coincidental
with the reboot. There could be some disk problem lurking in the future though.

[Shobayo Omololu]

Strings your /etc/lvmtab and note the content. Better still make a mackup and delete the original.

Then run vgscan to recreate the lvmtab.

You might be having proccessor setting problem on the Disk Array. Do you have the alternate paths enabled. Are you sure you are not using the alternate path for the Disk. This might have been configured before you.

Please, send your recent

IOSCAN -fnC disk
content of the /etc/lvmtab present and old.
vgdisplay of the group the disk belong to.

thanks

[Patrick Wessel]

Does it only happens after a powercycle of the box, or is a simple reboot enough? I ask this question, because you may deal with disk firmware problem

[Tim Malnati]

Here is a thought. I'm wondering if the minor address for the DLT device files are correct. To check it out, I would eliminate all of them for the DLT. I would probably prefer to just delete them; I'm not sure how rmsf will react if there is an address mismatch. I would not use insf to reinstall them either with this being as odd as it is. Instead, do a complete shutdown and power down of everything. Hopefully when you power up and reboot the system will generate them properly.

Also, there have been all kinds of patches issued that relate to the DLT. I would make sure that they are up to date before doing any of this. It may not be a bad idea to verify that the firmware is current as well, although upgrading it with your current situation may be a problem.

If none of this works, it may be time to get HP support involved. There may be a problem with the core I/O board causing all of this.

[Chris Moore]

Just to add to something that Michael Lampi said earlier - there is one more case where you don't want tape and disk sharing a SCSI bus and that's if your disks are hotswappable or are in an array. When you hotswap a disk most array controllers will reset the SCSI bus. Most tape drives will rewind the tape when they receive a reset. This means that if you swap a disk drive while your tape is being accessed the tape will be rewound and the tape operation will fail. In earlier versions of hp-ux the O/S didn't detect this and any new data would be silently written over the top of old data at the beginning of the tape. Hp-ux now handles the case of a tape being reset while it is open by refusing to write anymore to the tape.

[Carlos Fernandez Riera]

I think it is time to call Hp support too.

Let me tell:

On a K box i have a DLT 7000 and in backup time it hang. I cannot kill then process to get control of drive; the only thing ws shutdown box. After many days i call my support and ...

HE CHANGED one Fibre Chanel CARD. and tape never hang.

UH???