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

[Tomasz Chmielewski]

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?

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?


> 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.



-- 
Tomasz Chmielewski
http://wpkg.org