Dear Maintainer,

with a relatively simple setup:

local glusterfs, with a replica 2 volume, I tried to use tgtd with glfs. My tgt config was like so:

<target iqn.2018-07.de.xxxxxx:stor-b-0>
    vendor_id xxxxxx
    bs-type glfs
    bsopts "logfile=/var/log/bs-glfs.log;loglevel=3"
    write-cache off
    initiator-address 10.10.8.0/24
    backing-store "gv_b_0@127.0.0.1:/iSCSI_VOL1.img"
    backing-store "gv_b_0@127.0.0.1:/iSCSI_VOL2.img"
    controller_tid=10
</target>

...

/var/log/daemon.log gives me this endlessly
Jul 30 20:28:55 storage-b-02 tgtd[30479]: tgtd: abort_task_set(1349) found 38ec 0
Jul 30 20:28:55 storage-b-02 tgtd[30479]: tgtd: abort_cmd(1325) found 38ec 6
Jul 30 20:29:05 storage-b-02 tgtd[30479]: tgtd: abort_task_set(1349) found 38ec 0
Jul 30 20:29:05 storage-b-02 tgtd[30479]: tgtd: abort_cmd(1325) found 38ec 6

/var/log/messages contains this
Jul 30 20:34:17 storage-b-02 kernel: [436035.821673] tgtd[31394]: segfault at 220 ip 00007f6944b24dcb sp 00007fffdf64f800 error 4 in libgfapi.so.0.0.0[7f6944b1d000+25000]
Jul 30 20:37:39 storage-b-02 kernel: [436237.496969] tgtd[31627]: segfault at 220 ip 00007f370a520dcb sp 00007ffd3c51e5c0 error 4 in libgfapi.so.0.0.0[7f370a519000+25000]

I don't know, if it's related to the Volume-Files being 10T big, but it shouldn't, I think.

Thanks.

Hi,

Thanks for the report and apologies for the late response.

Downgrading severity to important. Although this bug makes the package
unusable for this particular scenario, it does not do so in general.

Unfortunately these messages don't help much. FWIW this could also be a
bug in glusterfs code.

Any chance you can give it a try with the version from unstable? Could
you also try to obtain a core dump or a backtrace using gdb and the
tgt-dbgsym and glusterfs-common-dbgsym packages?

Thanks,
Apollon