On Sun, 2002-10-06 at 10:45, James Bottomley wrote:
> > The reason this is a problem, is that when the LSI/StoragTEK
> > controllers present their luns, AVT is enabled.
>
> Others have answered the kernel questions, but just a note that you really
> don't want to do load balancing in this environment.
Hard-coding it to get load-balancing isn't terrible, and when the qlogic
driver works, the way I've got my controllers setup right now, it will
work just like powerpath, etc. There are no *ghosted* luns ATM, just the
*other luns*. Only when a failure occurrs, do I want them to be able to
be addressed down the alternate path. Since Target Reset is on, and the
driver is aware of all LUNs, it should allow the failover to occur. I'm
going to do some testing right now and see anyway, after adding
sparselun for the STK array.
> the way AVT works is that a LUN is locked to a specific controller (although
> it has a ghost on the alternate controller). If you send an I/O packet to the
> alternate controller, the controllers will immediately negotiate to transfer
> the LUN across (AVT is Auto Volume Transfer). It takes quite a while (in I/O
> terms) for the LUN to transfer, so if you load balance to this array you'll
> end up killing performance because most of the time will be spent oscillating
> the LUN.
>
> The way the setup was intended to work was for simple failover, where you only
> use an alternate path if the primary fails.
Currently things are more hard-coded than I'd like, but we're redundant
in many ways anyway. I'm going to see if the sparseluns bits at least
lets it keep working, but then I'll see if it actually does keep the
luns in more AVT time, than in operational time.
> In general, arrays that can gain performance from controller load balancing
> tend to be extremely expensive (EMC being the one that springs immediately to
> mind).
>
> James
>
-
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/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:55 EST