I've discovered why, but I'm not sure which direction to take with
helping out to get better closure/resolution with this.
The cause of the problem is that the QLogic driver doesn't to
transparent LUN masking it seems. The reason this is a problem, is that
when the LSI/StoragTEK controllers present their luns, AVT is enabled.
This causes LUN "ghosting" down each path from the storage to the HBAs.
This becomes a problem because when the Linux Driver is told to perform
load balancing via static bindings, the LUNs are now out of order.
(whether LUN ghosting is happening or not).
This is where transparent LUN masking would solve this problem.
Example:
HBA0 is told it's only allowed to address the even numbered volumes.
HBA1 is told it's only allowed to address the odd-numberd volumes.
When this happens, the driver can see all the volumes, and names them
0:0:0:0-16(or whatever the last number is) for HBA0, and then
1:0:0:0-16(or whatever thelast number is). But, the OS is not shown
that, it sees the real LUN numbers as presented by the storage.
(0,2,4,6,8,10,etc)
Linux is not allowed to address LUNs out of sequence, so searching for
further LUN numbers stops after 0, since 2 is the next one.
Is there a way to resolve this, either at the driver level, IMHO the
place it *should* happen. At the storage level, the place that it could
also happen, or in the Kernel?
For the time being, I'm using a temporary load balanced setup for
performance reasons since we just extended our two primary loops from 1
tray each, to 3 and 4 trays. Please advise ASAP, as in this
configuration, we cannot fail-over.
TIA
-- Austin Gonyou <austin@coremetrics.com> Systems Architect Coremetrics, Inc. Cel: 512-698-7250 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/