Hi Konrad and list,

Thanks for the reply. Please see my comments inline.

On May 19, 7:13 pm, Konrad Rzeszutek <[EMAIL PROTECTED]> wrote:
> 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?

ohh no - I wish I had :). I have created softlinks to some valid
devices. I have couple of SCSI disks, and I have created more than 100
links, spread across all of them so that not all links point to same
device. This is just a ploy to make iscsi-target feel that 100 targets
have been attached. Best part - it takes them silently, without
complaining. :)

> > 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?
I have added targets in ietd.conf on iscsi-target as:

Target iqn.2008-04.mydevice1.com:storage.disk1
  LUN 0 /dev/link1_0
  LUN 1 /dev/link1_1
Target iqn.2008-04.mydevice2.com:storage.disk2
  LUN 0 /dev/link2_0
  LUN 1 /dev/link2_1
Target iqn.2008-04.mydevicen.com:storage.diskn
  LUN 0 /dev/linkn_0

Now, whichever devices are on top of this list are thrown out.
Probably this as a result of some kind of target sorting as you said -
but, mydevice11 should come after mydevice100 isn't it?? but it
doesn't - iscsi-target simply throws (Dropping key) of top 'x' entries
where 'x = y - 90' where y is total number of devices (targets) added
in this list

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

Nope, I did not, though I should have. That would be my next step -
I did try using different names, but i think that is not the problem
because if I use the same target name as above "Target iqn.
2008-04.mydevice(n).com:storage.disk(n)" - iscsi-target is able to add
mydevice100 but not mydevice1. So, I have ruled out that the target
name is doing something strange.

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

Yup, this is what even I interpreted. The output of 'iscsi_discovery
<my ip> ' doesn't contain the name of those devices which have been
dropped and which have already been reported as "Dropping keys .." at
the iscsi-target side.

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

Precisely, this is what happened.

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

OK, but still, i feel mydevice23 should come before mydevice4 - that
way, mydevice23 should not be added even if it is at the bottom of the
list - but that is not happening. top 10-11 devices are simply dumped.

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

Ok, that sounds like a nice advice. Will do that. Right now I am
trying to figure out what exactly happens in this function to make
that function work.

Thanks for your response.

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