> The FC HBA driver put out by Qlogic works well but does a silly thing;
> it enumerates devices from 0, instead of by the actually loop ID.
> This makes it impossible to spec absolute paths to the device, as
> everything will shift when devices are moved on the FC loop.
There are several reasons why this is done:
Most modern SANs use soft loop ID which means that the ID is determined at
login time to the SAN, so changes as the SAN composition changes, therefore
the loop ID isn't really meaningful anyway.
FC drivers are coming around to the notion of persistent binding, which is
where you try to identify your devices by WWN instead of loop ID. This is
usually implemented as a mapping function which assigns a known SCSI pun to a
particular WWN regardless of the actual loop ID.
Version 5.x of the qla2x00 driver (in SuSE 7.3 and also on the IBM website but
not the qlogic website [yet]) does arbitrated loop. Now, since arbitrated
loop has two or more paths to the device through different ports with possibly
different loop IDs, which loop ID would you use as the "actual" one?
James Bottomley
On Friday 05 October 2001 10:47, you wrote:
> > The FC HBA driver put out by Qlogic works well but does a silly thing;
> > it enumerates devices from 0, instead of by the actually loop ID.
> > This makes it impossible to spec absolute paths to the device, as
> > everything will shift when devices are moved on the FC loop.
>
> There are several reasons why this is done:
Note that there is clear distiction between devices that are on the *local
loop* and those you obtain from fabric login. My bitch, and my patch, fixes
the logical issue that a local loop devices requesting a hard ID, should be
accessable by *that ID* from userland if it is available. Very simple, and
what the FC spec requires, and what the QLogic HBA BIOS does. However the
Qlogic Linux driver attempts to present all devices as found from unit 0.
This makes no sense because there are 2 assignment loops in the QLA source,
the second one for the purposes of login/softid resolution. I fixed the first
loop. The second loop still starts from zero and will catch any conflicts
from the first...
As for persistent binding, I just couldn't make it work with any of the
QLA2x00 drivers I tried. Their parsing code is just fubar.
Persistent binding is also not much fun to keep track of, and can run you out
of cmdline space *really* quick if you try to spec devices at boot.
For a small SAN, devices (bays) with hard id's are usually much more
desirable.
--
The time is now 22:19 (Totalitarian) - http://www.ccops.org/clock.html