On Thu, 23 Apr 2009 15:36:00 +0100 Chris Webb <chris@xxxxxxxxxxxx> wrote: > Ben Greear <greearb@xxxxxxxxxxxxxxx> 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 > exceeded. > > 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: you don't need to tell all the targets to an initiator. Do you really want one initiator to see 70 targets? It's unlikely. You can use the ACL list to configure targets exported to an initiator. In addition, discovery Session is not a must (you can configure targets on the initiator box by hand). > 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@xxxxxxxxxxxx> for more info: Note that tgt incorrectly ignores the MaxRecvDSL on Discovery Session. tgt can handle it on normal sessions. Anyway, I'll send two patches for this issue. I'm not interested in multiple PDUs in discovery session as I wrote above. But ignoring MaxRecvDSL on Discovery Session is not nice. So I want to fix it. -- 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
