[stgt] 0.9.6 released

Chris Webb chris at arachsys.com
Thu Apr 23 16:36:00 CEST 2009

Ben Greear <greearb at candelatech.com> writes:

> FUJITA Tomonori wrote:
>> Chris Webb (2):
>>       iscsi: fix sendtargets segfault with lots of targets
> How many targets do you support now?

This patch was reverted for 0.9.6, so tgtd will still fail to export more
than a fairly small number of targets, around 70 for me. However, a simpler
patch did go in, so at least it will no longer segfault when this limit is

If you need to export more than this, and are reasonably confident that your
initiator won't explode if it's passed more than 8k of data (if for example
you've set discovery.sendtargets.iscsi.MaxRecvDataSegmentLength to a
sensibly large value), the following patch will make tgtd grow the
response buffer as large as it needs to be to announce all your targets
all at once:

# HG changeset patch
# User Chris Webb <chris at arachsys.com>
# Date 1240496898 -3600
# Node ID 102da0d529797b0e558f96a34fdbbf0e18b400c4
# Parent  636d7691799cd17d1f1fe26e09974b1283773c3d

Signed-off-by: Chris Webb <chris at arachsys.com>

diff --git a/usr/iscsi/iscsid.c b/usr/iscsi/iscsid.c
--- a/usr/iscsi/iscsid.c
+++ b/usr/iscsi/iscsid.c
@@ -160,12 +160,18 @@
 	if (!conn->rsp.datasize)
 		conn->rsp.data = conn->rsp_buffer;
+	buffer = conn->rsp_buffer;
 	if (conn->rsp.datasize + len > INCOMING_BUFSIZE) {
-		log_warning("Dropping key (%s=%s)", key, value);
-		return;
+		buffer = realloc(buffer, conn->rsp.datasize + len);
+		if (buffer)
+			conn->rsp_buffer = buffer;
+		else {
+			log_warning("Dropping key (%s=%s)", key, value);
+			return;
+		}
-	buffer = conn->rsp_buffer;
 	buffer += conn->rsp.datasize;
 	conn->rsp.datasize += len;

I am running with this patch on our targets, as it's the only way I can use
tgtd to export all the devices from them. However, it is more likely to
allow the response to exceed MaxRecvDataSegmentLength than the small
hardcoded 8k limit in the released tgt. (Both stock tgt-0.9.6 and tgt with
this patch incorrectly ignore the MaxRecvDSL that the initiator requests. A
first cut at better behaviour would be to use the MaxRecvDSL as a limit
instead of a hardcoded INCOMING_BUFSIZE.) See the thread rooted at
<20090402234552.GA1927 at arachsys.com> for more info:



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

More information about the stgt mailing list