That's exactly the odd behavior I was talking about. At the time "the
tape was never seen" (as you say) I'm going to assume you had the default
binding disabled (ie. 'def_hba_binding' was set to something other then
'fcaw*' [for the Sbus version of the driver] or 'fca-pci*' [for the
PCI-bus version]). With default binding disabled and no corresponding
entry in either 'st.conf' or 'sd.conf' that explicitly states either the
WWNN, WWPN, or port ID of the tape drive or an entry that at least
specified the HBA from which the drive is seen, the drive will not be
assigned a SCSI target number. In the 'sd.conf' entry that you say fixed
things you'll notice that you do specify an HBA. This entry will match
any device seen on 'fcaw3' that does not have it's WWPN, WWNN, or port ID
specified on any other line in the 'sd.conf' file. Even if there is an
entry in the st.conf file that does explicitly specify the WWPN, WWNN, or
port ID for that tape drive, that entry will not be used. However, I'm
going to guess that if you had added the 'sd' entry to the 'st.conf' file
with a 'name="st"', you would have found that you would have been able to
see the drive.
Think of things this way. The specification for a persistent binding can
be looked at like an Internet address: WW{P,N}N@HBA
which is implemented by added either 'hba="......" wwnn="......"' or
'hba="......" wwpn="......"' (or 'hba="......" port="......"') to
*additional* entries in the 'st.conf' or 'sd.conf. (I say 'additional'
because I believe you should leave the existing entries alone; the new
entries need to go at the top of the file, before the standard/existing
ones).
An entry in the 'st.conf' or 'sd.conf' file with only an HBA specified is
equivalent to *@HBA which will match any device seen on that HBA for
which there does not exist an explicit WW{P,N}N@HBA entry with the
one caveat that all entries in the 'sd.conf' file are applied before all
other entries. That means any '*@HBA' entries in the 'sd.conf' file
override any 'WW{P,N}N@HBA' entries in the 'st.conf' file.
I agree that the behavior of the JNI drivers (both PCI and Sbus) are not
as logical (?) as one would like. And not having clear and complete
documentation dealing with both disk *and* tape devices certainly hasn't
helped things.
-- Tony Guzzi
Sr. Solutions Engineer, AssuredRestore team
Storability, Inc.
"Lumpkin, Buddy" <Buddy.Lumpkin AT nordstrom DOT com>
10/03/2001 05:56 PM
To: "'anthony.guzzi AT storability DOT com'" <anthony.guzzi AT
storability DOT com>,
veritas-bu AT mailman.eng.auburn DOT edu
cc: Buddy.Lumpkin AT nordstrom DOT com
Subject: RE: [Veritas-bu] Re: sd.conf entries affecting what
tape drives are seen
Right, but I have seen entries commented out in sd.conf keep the drive
from being seen. for instance:
# in sd.conf, standard entry for target3, lun0 commented out
#name="sd" class="scsi"
target=3 lun=0;
# Entry looked like this in st.conf
name="st" class="scsi"
target=3 lun=0;
and the tape was never seen so we added an entry that looked like this in
sd.conf:
name="sd" class="scsi" target=3 hba="fcaw3" lun=0;
and the tape drive was seen just fine.
--Buddy
-----Original Message-----
From: anthony.guzzi AT storability DOT com
[mailto:anthony.guzzi AT storability DOT com]
Sent: Wednesday, October 03, 2001 7:43 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Cc: Buddy.Lumpkin AT nordstrom DOT com
Subject: [Veritas-bu] Re: sd.conf entries affecting what tape drives are
seen
Buddy,
As far as the JNI driver using the information (I wouldn't exactly say
'parse') in the 'sd.conf' and 'st.conf', yes it does. I also appears to
use any binding information in the 'sg.conf' file (the Generic SCSI driver
config file). I'm going to hazard a guess that the JNI driver is using
any binding information it finds in any driver in the 'scsi' class (to
which the 'st', 'sd', and 'sg' drivers belong). Since the disks need to
be accessed first during a boot, I'm guessing the 'sd' info is first in
line with the 'st' and 'sg' info behind it. I'm also guessing that the
driver uses the info in the order it sees it and that order is the same as
the order the OS loaded the config info.
The 'technote' supplied with the driver from JNI deals mostly with disks
(almost all the examples are for the 'sd' driver). Tapes really aren't
addressed. As for the behavior as it pertains to the information in the
'st.conf' and 'sd.conf' files, what I reported all comes from a series of
tests I had to run on the driver in order to "qualify" it for us in
installation we support. As odd as it may sound, with default binding
enabled (i.e. the 'def_hba_binding' set to "fcaw*") , you can bind tape
drives by via lines in the 'sd.conf' (yes, "SCSI Disk" config file) that
begin 'name="sd"' just as long the 'hba=' and 'wwpn=' (or 'wwnn=', if you
use node name) contain the correct information for the tape drive. This
stuck me a very odd but it is how the driver behaves. No matter what I
put into the 'st.conf' (SCSI Tape) file, I couldn't get any of the
bindings in there to take effect. I've confirmed this in our lab and
it's easily reproducible.
Welcome to the world of persistent binding with JNI drivers.
-- Tony Guzzi
Sr. Solutions Engineer, AssuredRestore team
Storability, Inc.
|