On Mon, 06 Sep 2010 17:08:00 +0300 Or Gerlitz <ogerlitz@xxxxxxxxxxxx> wrote: > 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? Yeah, it might be the root cause. Can you confirmed that you successfully removed the connection? -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
