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" > is on the top of a SAN FS so you want tgt to read a file? > > I suppose that DRBD's tgt iSCSI cluster solution doesn't use a SAN > FS. So it might be better to use some protocols. > > http://www.linuxtag.org/2010/en/program/free-conference/popup/details.html?talkid=369 -- 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
