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

---
Shreyansh
--~--~---------~--~----~------------~-------~--~----~
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