Near as I can tell, make_scsi_dev determines which drives are connected
to the system and creates symlinks to those corresponding devices. When
you load your 'st' module, you get something like this:
Nov 30 16:08:52 kyle kernel: st: Version 20030406, bufsize 262144, max
init. bufs 8, s/g segs 16
Nov 30 16:08:52 kyle kernel: Attached scsi tape st0 at scsi1, channel 0,
id 0, lun 2
Nov 30 16:08:52 kyle kernel: Attached scsi tape st1 at scsi1, channel 0,
id 0, lun 3
Nov 30 16:08:52 kyle kernel: Attached scsi tape st2 at scsi1, channel 0,
id 0, lun 4
Nov 30 16:08:52 kyle kernel: Attached scsi tape st3 at scsi2, channel 0,
id 0, lun 5
Nov 30 16:08:52 kyle kernel: Attached scsi tape st4 at scsi2, channel 0,
id 0, lun 6
Nov 30 16:08:52 kyle kernel: Attached scsi tape st5 at scsi2, channel 0,
id 0, lun 7
When make_scsi_dev is run, it creates the following files in /dev/st/
(clearly, this is my unique configuration, YMMV)
H1C0T0L2 -> /dev/st0
H1C0T0L3 -> /dev/st1
H1C0T0L4 -> /dev/st2
H2C0T0L5 -> /dev/st3
H2C0T0L6 -> /dev/st4
H2C0T0L7 -> /dev/st5
NH1C0T0L2 -> /dev/nst0
NH1C0T0L3 -> /dev/nst1
NH1C0T0L4 -> /dev/nst2
NH2C0T0L5 -> /dev/nst3
NH2C0T0L6 -> /dev/nst4
NH2C0T0L7 -> /dev/nst5
Additionally, it creates files in /dev/sg/ that point to any SCSI device
(disks, tape, controllers, etc. This appears to aid in auto-detection,
etc). Look at /proc/scsi/scsi, everything in there should map to a
/dev/sgX device. Example:
H0C0T0L0 -> /dev/sg0
H1C0T0L0 -> /dev/sg1
...
H2C0T0L7 -> /dev/sg10
In your case, you should be able to create these symlinks yourself and
comment out the make_scsi_dev command. As people have pointed out, if
devices move around, then you'll have to recreate these - it isn't
elegant, but it might get you up and running.
________________________________
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Matthew
Johnson
Sent: Tuesday, December 05, 2006 12:57 PM
To: smpt at peppas.gr; Daniel Cox; veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] make_scsi_dev woes under Linux
Hello all,
I am having problems with the make_scsi_dev command as well. I have read
every thing out there and some are great ideas, however when I run it on
a particular system it crashed the system, nowhere have I read this
happening. if any one out there has info as to what the exact commands
that are run within the binary it would be great. this may be a system
problem and until i find out what is being run i am stuck between
Veritas and IBM.
Thanks
Matt
________________________________
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of smpt
Sent: Tuesday, August 15, 2006 10:36 PM
To: 'Daniel Cox'; veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] make_scsi_dev woes under Linux
If your environment is SSO I will give you 2 tips.
Wait for the completion of all backups and then run make_scsi_dev. Then
configure all Linux drives.
After that comment (#) the make_scsi_dev line at the NetBackup startup
script.
And do not reboot the system. If you do it you must run the
make_scsi_dev before netbackup start (and all drives must be idle)
I have install several linux systems and all working fine.
smpt
________________________________
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Daniel
Cox
Sent: Tuesday, August 15, 2006 7:32 PM
To: veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] make_scsi_dev woes under Linux
We've got a few media servers running NetBackup 5.1 MP5 under Linux
(RedHat AS4) and we're having no end of problems with FC attached tape
drive device mappings. I see when NB starts it runs make_scsi_dev, which
creates the following devices:
[ROOT at arcachnbmm03] ~ # ls -l /dev/st
total 0
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h0c0t0l0 -> /dev/st5
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h0c0t1l0 -> /dev/st4
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h0c0t2l0 -> /dev/st3
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h1c0t0l0 -> /dev/st1
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h1c0t1l0 -> /dev/st0
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h1c0t2l0 -> /dev/st2
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh0c0t0l0 -> /dev/nst5
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh0c0t1l0 -> /dev/nst4
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh0c0t2l0 -> /dev/nst3
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh1c0t0l0 -> /dev/nst1
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh1c0t1l0 -> /dev/nst0
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh1c0t2l0 -> /dev/nst2
There seems to be 2 big problems with this. The devices as created by
the OS (st*, nst*) can change due to HBA driver upgrades, PCI bus
detection order changes, somebody moving an HBA around on the system or
somebody moving a drive around in the SAN for various reasons (port
based zoning). Another problem is if any of the previous scenarios occur
then NB creates entirely different /dev/st/*, /dev/sg/* entries to
represent the new host/controller/target/lun detection order. Naturally
either of these scenarios results in drive and robotic library id
mismatches and either netbackup refusing to start or drives going into
perm DOWN state.
We can use 2.6 kernel udev rules to map WWNs to OS devices and always
have consistent /dev/st*, /dev/sg* device names to get around the first
problem; however the NB auto-created devices can still change so we are
stuck with things occasionally breaking and then we waste a fare amount
of time putting it all back together again.
Is there some better way of handling this?
Dan-
************************************************************************
*****
Note: The information contained in this message and any attachment to it
is privileged, confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by replying
to the message, and please delete it from your system. Thank you. NYSE
Group.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061206/48992b8a/attachment.html
|
