[Stgt-devel] [Scst-devel] Integration of SCST in the mainstream Linux kernel
Tue Feb 5 18:04:52 CET 2008
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.
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.
More information about the stgt