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 |