SEO

I have two supposedly identical SunFire V240 servers running Solaris 9,
each with four external HP DAT 40 drives off a PCI SCSI card. Both
systems have the drives with SCSI IDs 0,1,2, and 3 with the SCSI chain
terminated after the drive with SCSI ID 3. The primary server loads
its drives as /dev/rmt/0, /dev/rmt/1, /dev/rmt/2, and /dev/rmt/3. For
some reason, the second server is placing the drive with SCSI ID 3 as
/dev/rmt/9.

Crazier yet, it seems that any time I set a drive to a SCSI ID higher
than 2, Solaris sets it up as /dev/rmt/9 or higher (e.g., /dev/rmt/10)
during a reconfigure boot. Once setting the drive(s) to SCSI IDs back
in the 0-2 range, they go back to /dev/rmt/0 - /dev/rmt/2.

Any ideas on why these boxes are behaving differently, or where to look
for the difference? I want both servers to recognize the drives on the
same /dev/rmt aliases to avoid rewriting the backup scripts for each
box.

Michael J. Perkins

In comp.unix.solaris Michael Perkins <michael.j.perkins@verizon.net> wrote:
> Crazier yet, it seems that any time I set a drive to a SCSI ID higher
> than 2, Solaris sets it up as /dev/rmt/9 or higher (e.g., /dev/rmt/10)
> during a reconfigure boot. Once setting the drive(s) to SCSI IDs back
> in the 0-2 range, they go back to /dev/rmt/0 - /dev/rmt/2.

> Any ideas on why these boxes are behaving differently, or where to look
> for the difference? I want both servers to recognize the drives on the
> same /dev/rmt aliases to avoid rewriting the backup scripts for each
> box.

When a tape device is first seen (controller/target/LUN combo), then the
next free tape device ID is assigned to it. So the mapping from a scsi
device to a tape ID depends on the history of the host.

This mapping is maintained in the /etc/path_to_inst file. Look through
it for the "st" entries. If you're careful and keep a backup, you can
probably clean out all the "st" entries and reconfigure, or you could
manually massage them to the order you want.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

I double-checked the /etc/path_to_inst file. All "st" entries on the
second server are the same as my primary, which recognizes the DAT
drives as desired. I even ran a diff on them just to be sure.

I can still save a copy of the second server's /etc/path_to_inst file,
then delete all "st" lines and do a reconfigure boot, but I am not sure
it will help. Any other ideas, in case this does not resolve the
issue?

Michael J. Perkins

In comp.unix.solaris Michael Perkins <michael.j.perkins@verizon.net> wrote:
> I double-checked the /etc/path_to_inst file. All "st" entries on the
> second server are the same as my primary, which recognizes the DAT
> drives as desired. I even ran a diff on them just to be sure.

> I can still save a copy of the second server's /etc/path_to_inst file,
> then delete all "st" lines and do a reconfigure boot, but I am not sure
> it will help. Any other ideas, in case this does not resolve the
> issue?

You may also need to remove the existing links in /dev/rmt when you do
that.

That's the only thing I know of that controls this. I don't know why it
wouldn't help.

After done, check if the differences are between the rmt link and the
device (compare the output of ls -l /dev/rmt/*cbn), or between the
device and the hardware (do you have scsi cards in different slots or
something?).

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Removing the "st" entries from /etc/path_to_inst, rm-ing all st entries
in /dev/rmt, then doing a reconfigure boot did the trick.

Thanks for your help.

I have one more question, though. I am trying to figure out just what
the 'cbn' in the links found using ls -l /dev/rmt/*cbn means. I
thought 'c' was for character device and 'b' was for block device, with
'c' and 'b' being mutually exclusive, and 'n' meaning 'no rewind'.
Obviously, some part of my understanding is incorrect.

Thanks again,

Michael J. Perkins

In article <1140552560.491748.216080@g14g2000cwa.googlegroups .com> "Michael Perkins" <michael.j.perkins@verizon.net> writes:
>Removing the "st" entries from /etc/path_to_inst, rm-ing all st entries
>in /dev/rmt, then doing a reconfigure boot did the trick.
>
>Thanks for your help.
>
>I have one more question, though. I am trying to figure out just what
>the 'cbn' in the links found using ls -l /dev/rmt/*cbn means. I
>thought 'c' was for character device and 'b' was for block device, with
>'c' and 'b' being mutually exclusive, and 'n' meaning 'no rewind'.
>Obviously, some part of my understanding is incorrect.
>
>Thanks again,
>
>Michael J. Perkins

Have a look at the man page for "st".

The c means compressed, the b means BSD behaviour, and n means
no rewind on close.
--
Jeff Wieland

In comp.unix.solaris Michael Perkins <michael.j.perkins@verizon.net> wrote:
> I have one more question, though. I am trying to figure out just what
> the 'cbn' in the links found using ls -l /dev/rmt/*cbn means.

The 'st' man page has most of the details.

> I
> thought 'c' was for character device and 'b' was for block device, with
> 'c' and 'b' being mutually exclusive, and 'n' meaning 'no rewind'.
> Obviously, some part of my understanding is incorrect.

No. The first character is the "densisty" or "setting". Most tapes
don't have a per-character mode and operate only in block mode. For the
st devices, the four possible settings are 'l', 'm', 'h', and 'c' or 'u'
(c/u are equivalent). Depending on the drive and settings, these may or
may not represent different capabilities.

'b' is a flag that affects how the tape is positioned when the device is
closed. You're correct that the 'n' specifies the "no rewind" device.

% man st
[snip...]
/dev/rmt/[0- 127][l,m,h,u,c][b][n]
where l,m,h,u,c specifies the density (low, medium,
high, ultra/compressed), b the optional BSD behavior
(see mtio(7I)), and n the optional no rewind
behavior. For example, /dev/rmt/0lbn specifies unit 0,
low density, BSD behavior, and no rewind.
[...]

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >