To add to your “sparsely and vaguely
documented” documentation: We frequently have to reset one of the fibre
HBAs on our HP-UX master server attached to our fibre bridges for SCSI tape
drives on the L700 tape library to clear issues. The idea of having those HBAs
also be the point of entry for the disk drives would be a major issue for us.
We’ve and HP have never been able to
diagnose this as a problem with the HBAs themselves. It just appears that on
occasion things get hung.
If you’d prefer to think it doesn’t
really happen feel free to put yourself at risk. Personally I think real world
anecdotes trump theoretical white papers every time.
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of jim fred
Sent: Tuesday, November 20, 2007
5:28 PM
To:
VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Tape Drive
& Disk sharing HBAs - revisited
We all know that people have been telling us for years that you should
never share tape drives and disk on the HBAs.
These days the idea that the HBA could become the bottle neck for data
transmission are becoming less.
That leaves the other reason of tape FC-SCSI commands have
adverse affects upon the SAN operations of disks. The has been
sparsely and vaguely documented to the point where it may be more
mythology than reality with modern SAN, disk and tape technology.
Anybody attempted sharing emterprise grade disk [arrays] & LTO3
tape. OS not important but Windows 2003 would be interesting.
Anybody come across anything more definitive that these references
? .....
1. IBM Redbook sg246268 Implementing IBM Tape in Linux Widows p201+.
I queried IBM to provide more info....no reply form
them.
2. The following came from X-Info [Qlogic OEM] Qlogic
weren't interested but flipped my questions to two of their OEMs to
answer (no referecne cited) :
Tape resets can affect other devices on the SAN because when a tape
does its reset, it will also reset its FC connection (logs out and logs back
into the fabric nameserver of the switch). When a device logs out and
back into the switch, the switch will send out an RSCN (registered state change
notification) to the rest of the ports on the switch letting other FC devices
know that there was a change in the fabric. When the RSCN is received by
the initiators (servers and workstations), they in turn must log out and back
in to see what has changed on the nameserver. This process of
logging out and in can cause issues with the host OS (particularly with
Windows) because of the delays incurred during this logout/in. During
periods of high IO, the OS may just loose connection to the drives, or it may
kernel panic/blue screen the OS.
Qlogic switches have a feature called IOStreamguard that prevents RSCN's from
going to initiators that don't need to see them (i.e., the server does not have
an active connection to the tape, or the tape is not in its zone). Other
vendors switches can use zoning to restrict this as much as possible, but
RSCN's can still propagate outside the zones affected.
Also, tape resets are not as prevalent now as they used to be. The older
SCSI tape drives that were connected to the SAN via SCSI to FC Bridge were more
of a problem that the newer native FC tape drives. The native FC drives
are kinder to the fabric, and do not do resets unless they are actually
needed. Despite the advances made with the native FC tape drives, there
still can be issues, and that is why there is the recommendation of using a
separate fabric for the tape subsystem.
