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/20061205/9a979413/attachment.html
|
