[stgt] Large number of abort_task_set followed by conn_close

[Brian Schaefer]

Team,

I'm trying to stabilize my homebrew iSCSI server that I'm using as a
ESX datastore. Under heavy usage, i see the following behavior:

Jun 25 10:00:17 fileserver tgtd: abort_task_set(1150) found 177db9 0
[message repeats ~100 times, increasing the found hex address]
Jun 25 10:00:20 fileserver tgtd: conn_close(101) connection closed, 0x8cdbe8 70
Jun 25 10:00:20 fileserver tgtd: conn_close(107) sesson 0x8cdee0 1
Jun 25 10:00:20 fileserver tgtd: conn_close(101) connection closed, 0x8cc1f8 5
Jun 25 10:00:20 fileserver tgtd: conn_close(107) sesson 0x8cd400 1

I think this may be due to the fact that i'm using a /dev/loop0
devices as the backing store:

default-driver iscsi
<target iqn.2012-04.com.example:vmds200>
        backing-store /dev/loop0
        initiator-address 192.168.3.2
        initiator-address 192.168.3.6
</target>

In case it's relevant, /dev/loop0 gets created at boot (manually,
since this was supposed to be temporary anyway). It's a file i created
with DD, located on an MDADM RAID1 of 2x 2TB disks (2TB total
storage). The file itself if 500GB.

I'm running CentOS6 with kernel 2.6.32-220.17.1.el6.x86_64, and
scsi-target-utils-1.0.14-4.el6.x86_64.

In order to stabilize the system, would it be better to

a) migrate to the OSD storage type
b) migrate to real physical disks (probably another MDADM RAID1)
c) The loop device isn't the issue, I have something else messed up.
-- 


--Brian
--
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