If you stripe reads across enough spindles, you can saturate a fiber link. In most cases multipath is good for redundancy not throughout, but it can be used for better throughput if you can feed enough data. Also remember you can multipath with iSCSI and similar technologies benefit immensly from multipathing since the media throughput is lower. Sorry for incoherence - recently woke up after a 23 hour work day. Sent from my iPhone On May 22, 2010, at 12:59, "Yong Huang" <yong321@xxxxxxxxx> wrote: > While we're on this topic, here's some not very technical thought > on load balancing of multipath. When we talk about "load balance", > we always tend to associate it with overall performance improvement > (overall means scalability or throughput of multiple "clients", not > latency of a single "client"). For example, an Oracle cluster > database (called RAC by Oracle) allows more clients to connect to > the database without degraded response time. But here we're dealing > with multipath I/O. It's different in that the work done underneath > is on one single piece of storage hardware, a hard disk (or a > virtual one provided by some storage technology). Because read speed > on the storage itself is always much slower than any of the multi- > paths which is usually fiber channel, whether you have a single or > multiple paths to access the single slow disk will not provide > performance improvement. Am I missing anything obvious? > > No doubt multipath provides failover capability or failure > resilience. Even with that one advantage, it's worth it. > > Yong Huang > > > > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
