[stgt] Having a callback to set a redirector target, port and reason.
FUJITA Tomonori
fujita.tomonori at lab.ntt.co.jp
Sun Jun 20 04:07:36 CEST 2010
On Thu, 17 Jun 2010 16:24:14 -0700
Chandra Seetharaman <sekharan at us.ibm.com> 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 at us.ibm.com> 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 at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the stgt
mailing list