[Stgt-devel] [Scst-devel] Integration of SCST in the mainstream Linux kernel

[FUJITA Tomonori]

On Mon, 10 Mar 2008 08:08:37 +0100
Tomasz Chmielewski <mangoo at wpkg.org> wrote:

> FUJITA Tomonori schrieb:
> > From: Tomasz Chmielewski <mangoo at wpkg.org>
> > Subject: Re: [Stgt-devel] [Scst-devel] Integration of SCST in the mainstream Linux kernel
> > Date: Sun, 09 Mar 2008 19:35:52 +0100
> > 
> >> FUJITA Tomonori schrieb:
> >>> On Tue, 05 Feb 2008 18:04:52 +0100
> >>> Tomasz Chmielewski <mangoo at nospam.wpkg.org> wrote:
> >>>
> >>>> FUJITA Tomonori schrieb:
> >>>>
> >>>> (...)
> >>>>
> >>>>>> The problem with tgtd is that you can't start it (configured) in an
> >>>>>> "atomic" way.
> >>>>>> Usually, one will start tgtd and it's configuration in a script (I 
> >>>>>> replaced some parameters with "..." to make it shorter and more readable):
> >>>>> Thanks for the details. So the way to stop the daemon is not related
> >>>>> with your problem.
> >>>>>
> >>>>> It's easily fixable. Can you start a new thread about this on
> >>>>> stgt-devel mailing list? When we agree on the interface to start the
> >>>>> daemon, I'll implement it.
> >>>> Sure.
> >>>>
> >>>> 1. tgtd should not immediately background, but only when it's fully started?
> >>>>
> >>>> 2. tgtd should only start to listen if told so? tgtdadm --listen/--nolisten?
> >>> I was thinking about something like:
> >>>
> >>> tgtadm --op update --mode sys --name state -v running
> >> Hi,
> >>
> >> Have there been any changes in this area (I remember some discussion 
> >> here, but I can't find any posts)?
> >>
> >> Or is it still recommended to use iptables before/after starting tgtd?
> > 
> > Hmm, this doesn't work for your?
> > 
> > https://lists.berlios.de/pipermail/stgt-devel/2008-February/001380.html
> 
> Oh yes. That was the post I was looking for.
> 
> But it looks that there is still this issue then - so it may fail sometimes:
> 
>   there is a race
>   between the first and second operations (that is, you need to peform
>   the second right after the first, before the initiator tries to
>   connect). I'm fine with changing the default state to 'offline'.
> 
> ?

Then, at least, try that to see it works for you. After that, you can
say something like, it works for me, but I want the default state
'offline'.