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

[FUJITA Tomonori]

On Tue, 05 Feb 2008 18:04:52 +0100
Tomasz Chmielewski <mangoo at 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


> Actually, I only found this iptables workaround a few hours ago, after 
> sending the first mail to lkml.
> At first, I didn't realize my setup screws between tgtd and tgtdadm 
> commands (where I put "sleep 1" command).
> 
> Anyway - if tgtd can be only killed with KILL signal - isn't it risky to 
> do so? For example, something may be still cached, not full transferred? 
> Will SCSI stack take care of it properly?

No risk. It's just like power failure. The file system on the
initiator machine just sees the I/O failure. It will not break your
file system. With ext3, if power failure happens during a transaction,
it just aborts the transaction.


> > You want to reboot a server running target devices while initiators
> > connect to it. Rebooting the target server behind the initiators
> > seldom works. System adminstorators in my workplace reboot storage
> > devices once a year and tell us to shut down the initiator machines
> > that use them before that.
> 
> Technically, it should always work (assuming the timeout on the 
> initiators is bigger than time the target server reboot takes).
> By default, for open-iscsi, timeout is 120 seconds, but in practice 
> there is no problem in increasing it to even many days.

Well, what happens if people try to shut down the initiator box while
the target server is down?

It might work only in an environment which you control everything.