Operating System - HP-UX
1834598 Members
3852 Online
110069 Solutions
New Discussion

Re: Identifying tape drives

 
Stephen Keane
Honored Contributor

Identifying tape drives

I have written a C program (not a script) to walk the /dev/rmt directory and identify all potential tape devices. It tries to open each device in turn and send an ioctl inquiry to it to see if there is indeed a tape device there and get an inquiry string back. This was working fine until I started considering tape autochanger devices and tape libraries.

Since these aren't necessarily in the /dev/rmt directory, I need to walk the whole of the /dev directory recursively. So far so good. But I don't want to open every character device I find to see if it is a tape drive, so I wanted to maybe use the major number to filter the files down a bit first. This is where we actually get to the questions part of the thread :)

Q1. What are the drivers for tape/autochanger/library devices. I have a list of stape, tape0 and tape2 for tape devices, schgr for autochangers and sctl for generic SCSI nodes.

Q2. Is there a tape1 driver and if so is it still used and for what?

Q3. Can I rely on the major numbers being the same on all machines. e.g. on my B series, stape = 205, sctl = 203 etc. If I can't, is there a way programmatically (other than parsing the output of lsdev) to match the driver name with its major number?

Q4. Is there a standard set of directories under which I should find all the tape/autochanger/library devices, or is it at to the sys admins whim.

7 REPLIES 7
RAC_1
Honored Contributor

Re: Identifying tape drives

1. In addition to the drives you mentioned, I think, different library manufactures use different drives. I have heard about sony_tape, attd (i think IBM thing)

2. I have not seen tape1 drives being used.

3. You can rely on major number. It remains the same. In case of different unix flavors, it will vary.

No standard set of dirs. You can create device files in any dir you want. But this is rare.
There is no substitute to HARDWORK
Stephen Keane
Honored Contributor

Re: Identifying tape drives

Thanks RAC. I'm beginning to think I might have to scan the SCSI bus(es) to get the information I need. On one of the machines I've tested this on there are 2500 odd entries with major number corresponding to sctl in each of the directories /dev/scsi and /dev/rscsi (so 5000 odd device files in all) and it takes a couple of minutes to scan through them all to pull out the 2 files that are actually for tape drives. There must be a simpler way. :(

Stephen Keane
Honored Contributor

Re: Identifying tape drives

What about reading /etc/ioconfig, would that be reliable?
RAC_1
Honored Contributor

Re: Identifying tape drives

ioconfig file is binary file. So how do you scan it??
There is no substitute to HARDWORK
Stephen Keane
Honored Contributor

Re: Identifying tape drives

I'd previously written a C program to read it. The detail of its layout is buried in a header file somewhere. But the output on my system is somewhat confusing. e.g if I run it and grep out lines mentioning "tape" I get

Class [tape], Instance [0], H/W Path = 10.0.15.0.0.0, Driver [stape]
Class [tape], Instance [1], H/W Path = 10.0.15.0.2.0, Driver [spt]
Class [tape], Instance [2], H/W Path = 10.0.15.0.1.0, Driver [stape]
Class [tape], Instance [3], H/W Path = 10.0.15.0.4.0, Driver [stape]

But if I use ioscan only 10.0.15.0.4.0 actually has a tape drive on it, the other h/w paths don't exist.
RAC_1
Honored Contributor

Re: Identifying tape drives

That is strange. Why not just doing ioscan for particular class and prepare device file list from it and doing your c code onto those device files??
There is no substitute to HARDWORK
Stephen Keane
Honored Contributor

Re: Identifying tape drives

As a last resort, I'd have to go down that route, but I really don't like running shell commands in C programs and parsing the output. You can get into all sorts of problems if HP decide to subtly change the output of the command for example. Up until the point at which I started searching for autochanger/library devices, the scan I was doing was far quicker than ioscan in any case.