Depending on what you want to do, you may have some luck with configuring
/etc/devlink.tab to create the links the way you
want. From a machine here I have the following:
# find /devices -name st\*
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:n
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:b
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:bn
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:l
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:m
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:h
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:c
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:u
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:ln
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:mn
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:hn
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:cn
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:un
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:lb
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:mb
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:hb
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:cb
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:ub
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:lbn
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:mbn
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:hbn
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:cbn
/devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:ubn
I use the following entry in /etc/devlink.tab:
type=ddi_byte:tape;name=st;addr=2,0; rmt/\A1\M0
This tells devlinks (devfsadm for solaris > 7) to create links in /dev/rmt for
every tape device it finds, using the
convention:
/dev/rmt/<scsi id><minor component>
i.e.:
# ls -l /dev/rmt/
total 48
lrwxrwxrwx 1 root other 45 Jul 26 11:37 2 ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:
lrwxrwxrwx 1 root other 46 Jul 26 11:37 2b ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:b
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2bn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:bn
lrwxrwxrwx 1 root other 46 Jul 26 11:37 2c ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:c
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2cb ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:cb
lrwxrwxrwx 1 root other 48 Jul 26 11:37 2cbn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:cbn
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2cn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:cn
lrwxrwxrwx 1 root other 46 Jul 26 11:37 2h ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:h
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2hb ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:hb
lrwxrwxrwx 1 root other 48 Jul 26 11:37 2hbn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:hbn
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2hn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:hn
lrwxrwxrwx 1 root other 46 Jul 26 11:37 2l ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:l
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2lb ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:lb
lrwxrwxrwx 1 root other 48 Jul 26 11:37 2lbn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:lbn
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2ln ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:ln
lrwxrwxrwx 1 root other 46 Jul 26 11:37 2m ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:m
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2mb ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:mb
lrwxrwxrwx 1 root other 48 Jul 26 11:37 2mbn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:mbn
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2mn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:mn
lrwxrwxrwx 1 root other 46 Jul 26 11:37 2n ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:n
lrwxrwxrwx 1 root other 46 Jul 26 11:37 2u ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:u
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2ub ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:ub
lrwxrwxrwx 1 root other 48 Jul 26 11:37 2ubn ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:ubn
lrwxrwxrwx 1 root other 47 Jul 26 11:37 2un ->
../../devices/pci@1f,0/pci@1/scsi@2,1/st@2,0:un
The only caveat is that you have to specify the addr for every device attached
to your system, but you could probably script
that. In other words you can't just use an entry similar to this:
type=ddi_byte:tape;name=st; rmt/\A1\M0
to have automatically create links for every device.
Don't know if this is useful, but it's an alternative. Check out the devlinks,
devfsadm, and ddi_create_minor_node man pages,
and /usr/include/sys/sunddi.h.
George
On Thu, 9 Jan 2003, Donaldson, Mark wrote:
> I think you got it. To force the order I can only think of two ways:
> 1. recreate the sym-links in /dev/rmt ..or..
> 2. add the drives one-at-a-time and do your discovery after each.
>
> -M
>
> -----Original Message-----
> From: Shafto, Eric [mailto:Eric.Shafto AT DrKW DOT com]
> Sent: Thursday, January 09, 2003 6:08 AM
> To: 'veritas-bu AT jasons DOT us'; Donaldson, Mark
> Cc: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Procedure for creating /dev/rmt devices
>
>
> Thanks to you and to Mark for your replies. Unfortunately, I was not
> explicit enough (again!) in my message.
>
> Well, third time's the charm:
>
> I need the drives to be recognized in a particular order. I've done this in
> the past by tweaking lots of config files, and it was working until we added
> some more drives. At that point everything went to heck, and as someone on
> the list pointed out, cross-referenced drives can ruin your whole day.
>
> Not having the time to mess with the config files, I fixed it by deleting
> and manually recreating all 120 or so /dev/rmt links (for i in "" b bn c cb
> cbn ....). Not terribly painful, but not terribly stable either. If I were
> to delete /dev/rmt and do a devfsadm again, I know it'd mess me up.
>
> I have some more hardware to add, and a three-day weekend coming up, so I'd
> like to do it right. My documentation from the first experience is a little
> hazy (trying to remember exactly what I did after a two-day high-stress
> marathon), and I was hoping someone who had been through this might have a
> clearer explanation of what files needed to be tweaked and how.
>
> Thanks again for your patience, and thanks in advance for any assistance you
> may be able to render.
>
> -----Original Message-----
> From: veritas-bu AT jasons DOT us [mailto:veritas-bu AT jasons DOT us]
> Sent: Wednesday, January 08, 2003 4:44 PM
> To: Donaldson, Mark
> Cc: Shafto, Eric; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Procedure for creating /dev/rmt devices
>
>
> On Wed, 8 Jan 2003, Donaldson, Mark wrote:
>
> > If they're visible as targets then a simple reconfig reboot should handle
> > it. Either touch "/reconfigure" and reboot our "boot -r" from the BIOS
> > prompt.
>
> Similarly "reboot -- -r" (yes, you need all three dashes) will do the same
> thing with a single command.
>
> > You can check the drive visibility with "sgscan tape" beforehand or with a
> > "probe-scsi-all" at the BIOS prompt.
> >
> > Yet another alternative is to run:
> > "drvconfig && devlinks && disks && ports && tapes" as root on the cmd line
> > and it'll emulate the reconfigure boot - although experience tells me that
> > this sometimes locks up in high lun-count systems.
>
> With Solaris 2.7 and later you can use "devfsadm" instead of the string of
> commands listed above. And as Mark mentioned it can lock or appear to
> hang the machine if you have a large number LUNs but otherwise it should
> be fine. I've done this on systems with 10 SAN drive volumes mounted
> without a problem. Just have patience. The command can take several
> minutes to complete.
>
> > Make sure to use persistent addressing in your SAN scheme - you don't want
> > these addresses moving about.
>
> I'll second that. Cross-crossed drives can wreck your day.
>
> -Jason
>
> -----
> Jason K. Schechner - check out www.cauce.org and help ban spam-mail.
> =The difference between genius and stupidity is that genius has bounds.=
> ---There is no TRUTH. There is no REALITY. There is no CONSISTENCY.---
> ---There are no ABSOLUTE STATEMENTS I'm very probably wrong.---
>
>
> If you have received this e-mail in error or wish to read our e-mail
> disclaimer statement and monitoring policy, please refer to
> http://www.drkw.com/disc/email/ or contact the sender.
>
|
