[Stgt-devel] [Scst-devel] Integration of SCST in themainstreamLinux kernel

[Tomasz Chmielewski]

FUJITA Tomonori schrieb:

(...)

>>> I could make it as the startup (boot) option though I don't like it
>>> either but I think that it's less problematic to set the default state
>>> to 'offline'.
>> Either default to offline (bad for existing users) or give a startup 
> 
> Not only for existing users. People dislike extra operations.
> 
> I've used several commercial iSCSI target systems. All I need to do are
> setting up security (which initiators can connect) and luns with them.
> 
> 
>> option to tgtd (better). There is no other way, I guess (other than 
>> making it compile-time option, which is really bad).
> 
> There is another option. If tgtd has no targets, then tgtd closes a
> connection instead of sending a response. So you can change the state
> to offline, configure targets and then change the state to running.
> 
> Try this patch (against the current git head).

No, this won't work reliably if you have more than one target.

Let's say you have these targets; initiators connected to it:

tgtadm --lld iscsi --op new --mode target --tid 1 -T 
iqn.2008-03.com.example:san.target1
tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b 
/dev/san/target1
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

tgtadm --lld iscsi --op new --mode target --tid 2 -T 
iqn.2008-03.com.example:san.target2
tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b 
/dev/san/target2
tgtadm --lld iscsi --op bind --mode target --tid 2 -I ALL


You just upgraded and restarted your target without disconnecting the 
initiators. You have to go through these steps:

target              initiator
-----------------------------------
not started         trying to reconnect
start tgtd          trying to reconnect
sleep 2s            trying to reconnect
nothing configured  login I/O error - non fatal
configure target1   conn to target1 OK
no such target      conn to target2 FAIL
                     I/O error to target2
configure target2   too late, fatal, we lost it


With one target it will never fail.
With two targets it is not very likely to fail.

With lots of targets and initiators the things will fail, and a user 
which is not familiar with technicals will say "it fails randomly".

So I prefer the previous version of the patch, where the target is 
explicitly in offline state (with "tgtd --offline" flag, perhaps).


Or, is it possible not to fail connections to non-existing targets, but 
to answer that the (non-existing, not-yet-configured) target is 
offlined? Or will it be against RFCs?



-- 
Tomasz Chmielewski
http://wpkg.org