On Thu, 17 Jun 2010 16:24:14 -0700 Chandra Seetharaman <sekharan@xxxxxxxxxx> wrote: > On Thu, 2010-06-17 at 22:46 +0900, FUJITA Tomonori wrote: > > On Wed, 16 Jun 2010 16:13:17 -0700 > > Chandra Seetharaman <sekharan@xxxxxxxxxx> wrote: > > > > > Hi Tomo, > > > > > > Thinking along the direction of having redirector, think about the > > > following situation: > > > > > > A node has multiple ip addresses (say 10.0.0.1, 10.0.1.1, 10.0.2.1 and > > > 10.0.3.1) in different subnets and the "serving" tgtd is serving all > > > network ports(0:0:0:0). > > > > > > When the redirector tgtd has to respond with a "RedirectAddress", > > > instead always redirecting to a static address (say 10.0.0.1), it can > > > give an external entity an opportunity to provide a RedirectAddress > > > which is on the same subnet as the initiator. > > > > > > This can be done by providing multiple redirectAddress under a target, > > > but when we are talking about a cluster, failover, failback etc., it > > > will be handy to put that responsibility outside of stgt. > > > > Yeah, I think that it's a nice feature. You could add 'load balancing' > > to the above list. Redirecting intelligently would be nice. > > > > How tgtd talks to another component? IBM's tgt iSCSI cluster solution > > I was thinking we could use the callout mecahnism you added last week > (or some such). Basically the external tool should take the target name > and the initiator ip address and return a redirect "ipaddr:port:reason" Yeah, that's fine. The iSCSI code assumes that target_redirected() doesn't block. If we call an external program there, then we need to fix it. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
