On Mon, May 19, 2008 at 06:53:07AM -0700, Shrey wrote:
> Hi all,
> Further update on this topic:
> >
> > Thanks once again :) - If I manage to find/assert it, I will surely
> > post back.
> I tried to do an experiment to confirm the maximum number of available
> targets and LUNs with an initiator. I did:
> On the target machine:
> 1. I created softlinks for a device such that they are named /dev/link
> $i_$j where i varies from 1-100 and j varies from 0-10. Thus, I had
> links like "link1_0, link1_1, ...,link30_0,...,
> link99_0, ...link100_10".
> 2. Each link was a softlink of a valid SCSI device on the target. All

You have actually 100 SCSI devices on your target?

> this was pushed into the /etc/ietd.conf file and service iscsi-target
> was restarted. (Yup, I am using iscsi-target-0.4.16 on the target
> side.)
> 3. This gave me 100 targets, each having 10 LUNs - starting from
> mydisk1 to mydisk100 (as target names).
> On the initiator:
> 1. I set the discovery on this target machine IP. and tried to log in.
> result:
> Discovery itself is not able to add more than 89 (twice I got 90)
> devices. It simply doesn't get any information about the top 11
> devices from the ietd.conf file.

Which is that the first target wouldn't show up right?

> On the target, the message log contained something like "Dropping key
> (target ___ )" which, I found, was appearing from text_key_add()
> function from the iscsi-target package.
> The code is something like:
> ...
>       if (conn->rsp.datasize + len > INCOMING_BUFSIZE) {
>                 log_warning("Dropping key (%s=%s)", key, value);
>                 return;
>         }

Interesting. That does seem like a limitation in that code. Did you
try to change the INCOMING_BUFSIZE to a higher value? Or to decrease
the length of the target's name? So: iqn.2008.com:t1, iqn.2008.com:t2,
and so on?

> ...
> Initiator doesn't show any error, and infact the node list (iscsiadm -
> m node) doesn't display any device starting from mydevice1 -
> mydevice11 in the list.

Which would imply that the target didn't send that IQN to the initiator.

> I tried this experiment many times by
> 1. changing the number of LUNs,
> 2. changing the device being pointed to by the soft links,
> 3. changing the number of target devices defined in ietd,

So you added more targets and that didn't change it, and when
you lowered the target count it would be a lower amount
of block disks showing up on the initiator side?

> 4. making half the links point to one device, and other half to other
> 5. Shuffling the order of ietd defined target names (and each time
> starting 10-11, according to definition in ietd.conf, are not send by
> target, whatever there name be).

Yeah, it probably sorts them.
> Each time the result was same (atleast) - 89-90 can only be added.
> I am still trying to find what could be the possible bottleneck that
> is preventing me to add more devices - till then, I would really

Looks like a bug in iscsi-target. You probably show post this question
on its mailing list as well.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to