[stgt] back to forced deletion

[Or Gerlitz]

FUJITA Tomonori wrote:
>>> tgtadm --lld iscsi --mode target --op unbind --tid=1 -I ALL
>>> tgtadm --lld iscsi --mode conn --op delete --tid=1 --sid 3 --cid 0

> Yeah, it might be the root cause. Can you confirmed that you
> successfully removed the connection?

Tomo, when doing the above two commands without any traffic, things seem to go well, see the logs below, there's disconnect and next when the initiator attempts to connect, its rejected as of the no ACL for this target, however

> Sep  7 15:17:55 VSA1 tgtd: tgt_mgmt(346) 141 0 1 4 1 0 ffffffffffffffff initiator-address=ALL 19845
> Sep  7 15:18:00 VSA1 tgtd: tgt_mgmt(346) 120 0 1 2 -1 0 ffffffffffffffff  19845
> Sep  7 15:18:07 VSA1 tgtd: tgt_mgmt(346) 120 0 4 1 1 3 ffffffffffffffff  19845
> Sep  7 15:18:07 VSA1 tgtd: conn_close_force(233) close 3 0
> Sep  7 15:18:07 VSA1 tgtd: conn_close(100) connection closed, 0x472e128 1
> Sep  7 15:18:07 VSA1 tgtd: conn_close(106) sesson 0x472e390 1
> Sep  7 15:18:07 VSA1 tgtd: it_nexus_destroy(301) 1 3
> Sep  7 15:18:17 VSA1 tgtd: accept_connection(99) 5
> Sep  7 15:18:17 VSA1 tgtd: cmnd_exec_login(701) Login request (operational negotiation): 0
> Sep  7 15:18:17 VSA1 tgtd: iscsi_tcp_event_handler(167) connection closed 0x472e128
> Sep  7 15:18:17 VSA1 tgtd: conn_close(100) connection closed, 0x472e128 1

when done with inflight IO, if the logs are closed (normal operation), I get this

> Sep  7 15:30:28 VSA1 tgtd: conn_close_force(233) close 1 0
> Sep  7 15:30:28 VSA1 tgtd: conn_close(100) connection closed, 0x1c267128 5
> Sep  7 15:30:28 VSA1 tgtd: conn_close(106) sesson 0x1c267390 1
> Sep  7 15:30:28 VSA1 tgtd: tgt_event_modify(202) Cannot find event 12
> Sep  7 15:30:28 VSA1 tgtd: iscsi_event_modify(341) tgt_event_modify failed
> Sep  7 15:30:28 VSA1 tgtd: tgt_event_modify(202) Cannot find event 12
> Sep  7 15:30:28 VSA1 tgtd: iscsi_event_modify(341) tgt_event_modify failed
> Sep  7 15:30:28 VSA1 tgtd: tgt_event_modify(202) Cannot find event 12
> Sep  7 15:30:28 VSA1 tgtd: iscsi_event_modify(341) tgt_event_modify failed
> Sep  7 15:30:28 VSA1 tgtd: tgt_event_modify(202) Cannot find event 12
> Sep  7 15:30:28 VSA1 tgtd: iscsi_event_modify(341) tgt_event_modify failed
> Sep  7 15:30:31 VSA1 tgtd: conn_close(100) connection closed, 0x1c269118 1

and then $ tgtadm --op delete --mode logicalunit --tid=1  --lun 1 gives
> tgtadm: this logical unit is still active

it looks like (see next) tgt "thinks" it has a connection for this target
but what's actually going on is that the initiator keeps attempting to connect
and being rejected

> Target 1: tgt1.VSA1
>     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: 192.168.30.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: 79450 MB
>             Online: Yes
>             Removable media: No
>             Backing store type: rdwr
>             Backing store path: /dev/fioa
>             Backing store flags:
>     Account information:
>     ACL information:

as you can see in the initiator log

> Sep  7 15:33:28 vm-M5 kernel:  session28: iscsi_prep_mgmt_task mgmtpdu [op 0x3 hdr->itt 0x0 datalen 420]
> Sep  7 15:33:28 vm-M5 kernel:  session28: __iscsi2_complete_pdu [op 0x23 cid 0 itt 0x0 len 0]
> Sep  7 15:33:28 vm-M5 kernel:  session28: iscsi_complete_task complete task itt 0x0 state 3 sc 0000000000000000
> Sep  7 15:33:28 vm-M5 kernel:  session28: iscsi_free_task freeing task itt 0x0 state 1 sc 0000000000000000
> Sep  7 15:33:28 vm-M5 iscsid: conn 0 login rejected: initiator error - target not found (02/03)

when done with logs open, we get a segmentation fault of tgtd, I am not sure why yesterday we didn't had this, one thing which changed is the IO rate, the env I test with today has 30K IOPS wheres yesterday I had 7K IOPS, I tend to think that the crash with logs open is a different problem which is not related to the conn forced deletion

Or.
--
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