schgr or sctl??

[Alan Shearer_1]

Hi,

I'm configuring a new 10 drive library. This is the first robotic library I've worked on. I'm fairly clear on determining the devices in ioscan etc and using mknod from the docs I've read.

Where I'm confused is that it states the choice is between using spt and sctl - no problem, we are sctl as it's an RP7410. However, I see schgr next to the SCSI target I configured on the library.

It would seem that I have to reference the SCSI target and LUN id when I mknod my /dev/picker using the sctl device #.

What is the importance of the schgr device line?

How come I can use either my new /dev/picker device file or the /dev/rac/c8t0d0 associated with the schgr H/W path?

Do I need a /dev/picker. If so, which one should I use for our backup software?

I've looked through various postings and can't really find a decisive answer to this. I'd appreciate it if anyone could help me.

Cheers, Alan

[Leif Halvarsson_2]

Hi,

Below is an example of the device file for one of our librarys:

crw-rw-r-- 1 root sys 203 0x050000 Jul 2 2003 /dev/picker1


You should use the sctl driver, not the schgr (if I remember correct, this driver is for MO-jukeboxes). You have to create the devicefile for the picker manually, (you can name it anything you want).


Note, when using the sctl driver, the picker is listed as UNCLAIMED UNKNOWN in ioscan, this is normal (see ex. below).

unknown -1 0/2/0/0.1.0.255.0.0.0 UNCLAIMED UNKNOWN COMPAQ MSL5000 Series

[A. Clay Stephenson]

In almost all cases, sctl (SCSI Pass-thru) is the device you want. Do an lsdev and look for "sctl" to get the character device major number (typically 203 dec). Do a man scsi_ctl to see how to construct the minor device number using the mknod command.

[Alzhy]

This is what I have, a bridged (SCSI-FC) Compaq Libarary:

autoch 17 0/8/0/0.71.4.255.0.0.0 schgr CLAIMED DEVICE COMPAQ
ESL9000 Series
tape 222 0/8/0/0.71.4.255.0.0.1 stape CLAIMED DEVICE DEC
TZ89 (C) DEC
tape 97 0/8/0/0.71.4.255.0.0.2 stape CLAIMED DEVICE DEC
TZ89 (C) DEC
tape 98 0/8/0/0.71.4.255.0.0.3 stape CLAIMED DEVICE DEC
TZ89 (C) DEC
tape 99 0/8/0/0.71.4.255.0.0.4 stape CLAIMED DEVICE DEC


We use NetBackup and I believe its documentation explains very well how to configure the robotics and the drives.

And yes we use the sctl driverbut the robot is bound to the schgr driver. Here's my device entry... note 203 is the sctl driver..


crw------- 1 root sys 203 0x080000 Jan 21 13:37 c8t0l0

[V.Tamilvanan]

Hi,
Create a Soft link for the /dev/rac/c8t0d0 to /dev/picker.

#ln -s /dev/rac/c8t0d0 /dev/picker

[Ralf Loehmann_2]

Hello Alan,

you need the sctl driver for the most applications, the schgr is an older driver, which was lately only used for diagnostic purpose. Here a pretty good document how to configure and also how to test in HP-UX.

http://openview.hp.com/sso/ecare/getsupportdoc?docid=OV-EN010365

This document was written from the OMNIBACK/Dataprotector team, but is written for all use.

Cheers,
Ralf.

[George Neill]

The type of SCSI Robotic Driver in use depends on the hardware.
Systems equipped with the GSC/HSC or PCI bus have the SCSI
Autochanger Driver named schgr, and systems equipped with the EISA
bus have the SCSI Pass-Through Driver named sctl, which is already
built in the kernel. However, the SCSI Pass-Through Driver used on HP
Servers with an NIO Bus is named spt. It is installed on the system
without being built into the kernel by default.

The above is from the current DataProtector 5.1 installation documentation page B-26.

Wheather or not you need the /dev/picker depends on the software you are using. But you could create a link to the /de/rac/c?t?d? as noted above just to be in case it is needed.

George

[Alan Shearer_1]

Hi All,

Thanks to everybody who replied, I really appreciate you taking the time to respond.

All the feedback was pretty much in agreement with what I already understood.

I don't think you should create a link to the /dev/rac/c8t0d0 device as it's driver number is 231, which relates to schgr, which you are not supposed to use.

I still do feel that I don't know the answer to my original questions.

*********
It would seem that I have to reference the SCSI target and LUN id when I mknod my /dev/picker using the sctl device #.

What is the importance of the schgr device line?

How come I can use either my new /dev/picker device file or the /dev/rac/c8t0d0 associated with the schgr H/W path?

Do I need a /dev/picker. If so, which one should I use for our backup software?
**********

Though I don't want those who responded to think it is a slight on them in anyway.

Thanks, Alan

[A. Clay Stephenson]

Because it makes absolutely what you call it. You could name it /etc/MickeyMouse and it would work just as well as long as the major/minor device number tuple refers to the correct device. The name is for us dumb humans; the major and minor device numbers associated with a device node are what matters to the box.

[Scott McIntosh_2]

Add schgr to the kernel so you have an entry in ioscan you can find using ioscan -kfnC autoch. Easy ref when trying to find the robotics.

But don't use schgr for a tape library robotics. schgr and sctl both can function as a "scsi pass through" driver, but neither are a true pass-through like spt (which is for the SIO/NIO/PB/pick-your-term bus though). sctl messes with the scsi commands less than schgr. schgr will work usually, until things start getting non-optimal. Then you'll start seeing errors when there shouldn't be, etc.

schgr is only autobound via the kernel because that's the default driver for the autochanger device class, not because it's the better selection.

I don't recommend removing schgr from the kernel and hard binding sctl to the hardware. No need for that, and just more custom work to maintain.

The minor number will be the same between the two except that the lun digit for sctl will be half of that for schgr (so 0x0c3400 for schgr will be 0x0c3200 for sctl; in both cases, the ctd will be c12t3d2).

Thanks,
Scott
HP Support