Sol 9 Incorrectly Loading External DAT Drives - SUN

This is a discussion on Sol 9 Incorrectly Loading External DAT Drives - SUN ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Sol 9 Incorrectly Loading External DAT Drives

  1. Sol 9 Incorrectly Loading External DAT Drives

    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


  2. Re: Sol 9 Incorrectly Loading External DAT Drives

    In comp.unix.solaris Michael Perkins 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. >

  3. Re: Sol 9 Incorrectly Loading External DAT Drives

    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


  4. Re: Sol 9 Incorrectly Loading External DAT Drives

    In comp.unix.solaris Michael Perkins 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. >

  5. Re: Sol 9 Incorrectly Loading External DAT Drives

    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


  6. Re: Sol 9 Incorrectly Loading External DAT Drives

    In article <1140552560.491748.216080@g14g2000cwa.googlegroups. com> "Michael Perkins" 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

  7. Re: Sol 9 Incorrectly Loading External DAT Drives

    In comp.unix.solaris Michael Perkins 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. >

+ Reply to Thread