[stgt] back to forced deletion

[Or Gerlitz]

Hi Tomo,

I'm trying to implement a "forced deletion" with tgt, namely remove ACL, initiator connections, luns and target in that order. When done under IO load, sometimes (many times), it doesn't work, and the initiator is still able to issue IO after the delete sequence is executed. 

Basically, the sequence we use is

> tgtadm --lld iscsi --mode target --op unbind --tid=X -I ALL
> tgtadm --lld iscsi --mode conn --op delete --tid=X --sid Y --cid 0
> tgtadm --op delete --mode logicalunit --tid=X --lun 1
> tgtadm --lld iscsi --mode target --op delete --tid=X

This and/or similar issues were reported also last year, over the "can't force-remove targets" e.g @ http://markmail.org/message/rxsgwb7c3dwiz7uv

see below the actual failure. I wonder what would be the correct action to fix this out, we're using the latest tgt (commit 8523a8343a0d627c2c484ef16804aee685d5030b)

Or.

> Target 1: tgt1.celery
>     System information:
>         Driver: iscsi
>         State: ready
>     I_T nexus information:
>         I_T nexus: 1
>             Initiator: iqn.1994-05.com.redhat:66d380effa
>             Connection: 0
>                 IP Address: 172.30.25.167
>     LUN information:
>         LUN: 0
>             Type: controller
>             SCSI ID: IET     00010000
>             SCSI SN: beaf10
>             Size: 0 MB
>             Online: Yes
>             Removable media: No
>             Backing store type: null
>             Backing store path: None
>             Backing store flags:
>         LUN: 1
>             Type: disk
>             SCSI ID: 1
>             SCSI SN: 1
>             Size: 40008 MB
>             Online: Yes
>             Removable media: No
>             Backing store type: rdwr
>             Backing store path: /dev/sde
>             Backing store flags:
>     Account information:
>     ACL information:
>         ALL

without inflight IO - things go well

> Sep  6 16:48:32 celery tgtd: tgt_mgmt(346) 120 0 1 2 -1 0 ffffffffffffffff  3982
> Sep  6 16:48:32 celery tgtd: tgt_mgmt(346) 141 0 1 4 1 0 ffffffffffffffff initiator-address=ALL 3982
> Sep  6 16:48:32 celery tgtd: tgt_mgmt(346) 120 0 4 1 1 1 ffffffffffffffff  3982
> Sep  6 16:48:32 celery tgtd: conn_close_force(233) close 1 0
> Sep  6 16:48:32 celery tgtd: conn_close(100) connection closed, 0x13ebb128 1
> Sep  6 16:48:32 celery tgtd: conn_close(106) sesson 0x13ebb390 1
> Sep  6 16:48:32 celery tgtd: it_nexus_destroy(301) 1 1
> Sep  6 16:48:32 celery tgtd: tgt_mgmt(346) 120 0 2 1 1 0 1  3982
> Sep  6 16:48:32 celery tgtd: tgt_device_destroy(622) 1 1
> Sep  6 16:48:32 celery tgtd: tgt_mgmt(346) 120 0 1 1 1 0 ffffffffffffffff  3982
> Sep  6 16:48:32 celery tgtd: tgt_device_destroy(622) 1 0
> Sep  6 16:48:32 celery tgtd: tgt_mgmt(346) 120 0 1 2 -1 0 ffffffffffffffff  3982
> Sep  6 16:48:35 celery tgtd: accept_connection(99) 5


with inflight IO

> tgtadm --lld iscsi --mode target --op unbind --tid=1 -I ALL
> tgtadm --lld iscsi --mode conn --op delete --tid=1 --sid 3 --cid 0
> tgtadm --op delete --mode logicalunit --tid=1 --lun 1
> tgtadm: this logical unit is still active
> tgtadm --lld iscsi --mode target --op delete --tid=1
> tgtadm: this target is still active

Is it possible that "tgtadm --lld iscsi --mode conn --op delete --tid=1 --sid 3 --cid 0" was silently failing and as such the logical unit is still active and can't be removed?
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html