You're correct, it is in all likelihood the behavior of the JNI driver.
I'm dealing with the same issues right now. One additional point I'd like
to make is the driver appears to use the definitions in the 'sd.conf' file
before any in the 'st.conf'. This means that if you have a line in the
'sd.conf' file that reads something like
name="sd" class="scsi" target=2 hba="fcaw1";
if target 2 is not yet assigned when the tape drives are being processed
(ie. there is not disk on HBA fcaw1 that wants target 2), even if there is
a line in the 'st.conf' file with a 'target=5 hba="fcaw1"
wwpn="........."', the tape drive will be assigned target 2; the line in
the 'st.conf' will be ignored because that fibre device will already have
been bound to a SCSI target.
When it comes to fibre devices, I'd have to say its best make sure if you
specify and a 'hba=' entry on any line in either the 'st.conf' or the
'st.conf', you should always specify a 'wwpn=', 'wwnn=', or 'port=' entry
on the same line. Don't let the system assign it on its own.
-- Tony Guzzi
Sr. Solutions Engineer, AssuredRestore team
Storability, Inc.
From: Mike Andres <mike_andres AT cnt DOT com>
To: "Lumpkin, Buddy" <Buddy.Lumpkin AT nordstrom DOT com>,
veritas-bu AT mailman.eng.auburn DOT edu,
"'veritas-vx AT mailman.eng.auburn DOT edu'"
<veritas-vx AT mailman.eng.auburn DOT edu>,
"'sunmanager AT sunmanager DOT org'"
<sunmanager AT sunmanager DOT org>,
emc-l AT lists.blinky-lights DOT org
Date: Tue, 2 Oct 2001 08:55:41 -0500
Subject: [Veritas-bu] RE: [Veritas-vx] sd.conf entries affecting what tape
drives are s
een (GURU's and H ACKERS please read!)
Buddy,
I believe what you are seeing is a side effect of the JNI driver. If,
in
the fcaw.conf file you have a line such as "def_hba_binding = fcaw*",
change
it. This setting unleashes the fcaw driver to bind to any device it sees,
at any target/LUN that is outlined in any SCSI compliant driver config
file.
This inlcludes sd, st, ses, and others. You have very little control over
how things are configured with this setting, especially in a SAN
environent.
For instance, if you wish to have a tape drive set up on a SAN at target
1,
LUN 0, on fcaw3, and you have "def_hba_binding = fcaw*" in the fcaw.conf
file, if JNI scans the ses.conf file first and a device responds at target
1, LUN 0, this controller cannot bind to the tape drive at that target/LUN
cause it is already assigned. A better way is to set the def_hba_binding
value to "non-jni" or any string that does not match the JNI driver name.
Next, in whatever driver config file you wish to configure a device, use
the
"hba = " directive to instruct that driver instance to go and look for the
device you wish to see.
-mike
-----Original Message-----
From: Lumpkin, Buddy [mailto:Buddy.Lumpkin AT nordstrom DOT com]
Sent: Monday, October 01, 2001 1:09 PM
To: veritas-bu AT mailman.eng.auburn DOT edu;
'veritas-vx AT mailman.eng.auburn DOT edu'; 'sunmanager AT sunmanager DOT org';
emc-l AT lists.blinky-lights DOT org
Subject: [Veritas-vx] sd.conf entries affecting what tape drives are
seen (GURU's and H ACKERS please read!)
Hello All,
We have seen many times where a custom sd.conf file prevents the system
(Solaris 2.x) from seeing tape drives.
Example:
an entry commented out in sd.conf for target 3, lun 0 prevents a tape
drive
from being seen at this target and LUN.
another example would be any entry that specifies a parent, hba or wwn. So
in the above instance if the line wasn't commented out but rather had a
line
that also specified something like:
name="sd" class="scsi" target=2 hba="fcaw3" lun=0;
Unless there were an entry like this for hba="fcaw0" a drive on fcaw0 at
the
same target and lun would not be seen.
It seems to me that the st driver requires the sd driver for scsi access
or
at minimum relies on the sd driver to "probe" for scsi devices.
Many people have argued this point with me but I have seen this behavior
too
many times ... the sd driver definately has an affect on tape drive
visibility.
When you look at the man page for sd, it says "sd - SCSI disk and
ATAPI/SCSI
CD-ROM device driver".
Has anyone else witnessed this behaviour?
If so, does anyone have a clear understanding of how the two work
together?
By what I have observed, im visualizing some kind of abstraction like
this:
tape drive
--------------
Fibre(JNI)
---------------
fcaw driver
---------------
sd driver
---------------
st driver
---------------
kernel
---------------
ioctl() system calls to control tape device
Does it really work this way?
I looked around in the Solaris source code and could not find the sd or
the
st driver anywhere, does anyone know where I can find them?
TIA
--- Buddy
|
