Maximum LUN support

[Shrey]

Dear All,

I started using/studying open-iscsi recently. I was wondering if there
is any hard-coded limit to number of targets devices that can
discovered per iSCSI target? Is there any hard-coded limit on the
number of LUNs supported per target device (assuming that somehow HBA
on iscsi target doesn't present any limit) ?

Actually I have a simple setup wherein Machine A and Machine B are
connected over a 10Gbps Ethernet, and Machine B has a HBA to a single
SCSI disk. Machine A has open-iscsi-2.0-869.  Machine B is running
iscsi-target-0.4.16. I wanted to know the peak capability of the open-
iscsi initiator for certain study.

Hope I am able to put forward my doubt clearly. I myself haven't
searching for this too hard - but at least I couldn't find anything in
the docs/README.

Thanks in advance
---
Shrey

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

Re: IPv4/IPv6 initiator-target--automatic mapping of targets

[Padmanabhan]

> What distro are you using?

I am using FC 8 // 2.6 kernel
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: target*/*/block:change

[Konrad Rzeszutek]

On Wed, May 14, 2008 at 01:29:43PM +0200, Stefan de Konink wrote:
> 
> What was the reason for adding the block device name to the block symlink
> if this symlink already provides this name?

I find it useful when doing this:

 find /sys/class/iscsi_session/session*/device/ -name block:* | sed 's/.*:/'

And I can get all of the block disks names without have to read the link(s).

> 
> It probably breaks everything that uses this block path directly to find
> out the device it is pointing to.

Not sure what you mean. This sysfs structure has been in existence for some 
time (since 2.0-754)
so code written to use this format is not broken.

I would think that code that uses the block device would be using the
/sys/block/sdX interface instead?


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

Feature: Support sysfs/firmware/ibft parsing.

[Konrad Rzeszutek]

Mike,

I've added the bug-fixes and the missing functionality you put in RHEL5.2 to 
make this
one check-in. But if you would like me to split it out in two posts: initial 
code and
bugfix I would be more than happy to do this.

This patch parses the kernel exposing the iBFT information via the sysfs entry.
Here is the git commit from the kernel.org:

commit 138fe4e069798d9aa948a5402ff15e58f483ee4e
Author: Konrad Rzeszutek <[EMAIL PROTECTED]>
Date:   Wed Apr 9 19:50:41 2008 -0700

Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along 
with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table?  It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target.  Currently the iSCSI
information is hard-coded in the initrd.  The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do  echo -n "$a: ";  
cat $a; done
/sys/firmware/ibft/target0/target-name: 
iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: 
iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0



 Makefile |3 
 fw_entry.c   |3 
 fwparam_ibft.h   |3 
 fwparam_ibft_sysfs.c |  330 +++
 4 files changed, 336 insertions(+), 3 deletions(-)


 Signed-off-by:  Konrad Rzeszutek <[EMAIL PROTECTED]>


diff --git a/utils/fwparam_ibft/Makefile b/utils/fwparam_ibft/Makefile
index 6d7d00a..71d27a9 100644
--- a/utils/fwparam_ibft/Makefile
+++ b/utils/fwparam_ibft/Makefile
@@ -20,8 +20,7 @@
 #  Doug Maxey <[EMAIL PROTECTED]>
 #  "Prasanna Mumbai" <[EMAIL PROTECTED]>
 #
-
-OBJS := fwparam_ibft.o fw_entry.o
+OBJS := fwparam_ibft.o fw_entry.o fwparam_ibft_sysfs.o
 OBJS += prom_lex.o prom_parse.tab.o fwparam_ppc.o
 CLEANFILES = $(OBJS) *.output *~
 
diff --git a/utils/fwparam_ibft/fw_entry.c b/utils/fwparam_ibft/fw_entry.c
index 915bbb7..e575da4 100644
--- a/utils/fwparam_ibft/fw_entry.c
+++ b/utils/fwparam_ibft/fw_entry.c
@@ -29,7 +29,10 @@ int fw_get_entry(struct boot_context *context, const char 
*filepath)
 
ret = fwparam_ppc(context, filepath);
if (ret)
+   ret = fwparam_ibft_sysfs(context, filepath);
+   if (ret)
ret = fwparam_ibft(context, filepath);
+
return ret;
 }
 
diff --git a/utils/fwparam_ibft/fwparam_ibft.h 
b/utils/fwparam_ibft/fwparam_ibft.h
index 90ecb17..0eed9cd 100644
--- a/utils/fwparam_ibft/fwparam_ibft.h
+++ b/utils/fwparam_ibft/fwparam_ibft.h
@@ -153,6 +153,7 @@ extern int dev_count;
 #define TARGET "target"
 
 extern int fwparam_ibft(struct boot_context *context, const char *filepath);
+extern int fwparam_ibft_sysfs(struct boot_context *context,
+   const char *filepath);
 extern int fwparam_ppc(struct boot_context *context, const char *filepath);
-
 #endif /* FWPARAM_IBFT_H_ */
diff --git a/utils/fwparam_ibft/fwparam_ibft_sysfs.c 
b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
new file mode 100644
index 000..004a1ea
--- /dev/null
+++ b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
@@ -0,0 +1,330 @@
+/*
+ * Copyright (C) IBM Corporation. 2007
+ * Copyright (C) Konrad Rzeszutek, 2008
+ * Author: Konrad Rzeszutek <[EMAIL PROTECTED]>
+ *
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#define  _XOPEN_SOURC

Re: iSCSI Timeout

[Mike Christie]

An Oneironaut wrote:
> Hey Mike,
> 
> I accidentally deleted my log so I can't give you anymore :-\.
> But the error (1011) is there in the dump I sent.  I also have timed

Sorry, you are right. I missed it.

> the error and it looks like it takes about 20 to 21 seconds.  I have
> also found a work around.  I changed my timeout time to 14
> Days(1209600s) and the timeout seems to be working now.  Hope this
> helps.
> 


Ah thanks. Yeah, it looks like a roll over issue with the kernel timer 
code. I am still investigating to see if it was fixed upstream or if 
such long timers are supported. Thanks for the info.


> -JD
> 
> On May 14, 9:11 am, Mike Christie <[EMAIL PROTECTED]> wrote:
>> An Oneironaut wrote:
>>> I gave this a try but now when I set the timeout for a really long
>>> period and disconnect my iSCSI device to test it, after about 2
>>> minutes I get this:
>>> <28>May 13 13:15:48 localhost iscsid: Kernel reported iSCSI connection
>>> 4:0 error (1011) state (3)
>>> <31>May 13 13:15:48 localhost iscsid: re-opening session 4 (reopen_cnt
>>> 1)
>>> <31>May 13 13:15:48 localhost iscsid: thread 0807e1cc delete: state 2
>>> <31>May 13 13:15:48 localhost iscsid: in kstop_conn
>>> <31>May 13 13:15:48 localhost iscsid: in __kipc_call
>>> <31>May 13 13:15:48 localhost iscsid: in kwritev
>>> <6>May 13 13:15:59 localhost kernel:  session4: iscsi: session
>>> recovery timed out after 2678400 secs
>> Could you send the part of the log where the error is detected (it would
>> say something about iscsi connection error (1011)), so we know the
>> timing better?
>>
>>
>>
>>> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
>>> - not ready after error recovery
>>> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
>>> - not ready after error recovery
>>> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
>>> - not ready after error recovery
>>> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
>>> - not ready after error recovery
>>> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
>>> - not ready after error recovery
>>> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
>>> - not ready after error recovery
>>> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: SCSI error: return
>>> code = 0x2
>>> <4>May 13 13:15:59 localhost kernel: end_request: I/O error, dev sdb,
>>> sector 75752
>>> <3>May 13 13:15:59 localhost kernel: Buffer I/O error on device sdb,
>>> logical block 9469
>>> <4>May 13 13:15:59 localhost kernel: lost page write due to I/O error
>>> on sdb
>>> I am using an older version of open iscsi, Version 2.0-865.9.  Is this
>>> why I am losing the connection before the time out period?
>> I do not think so. It looks like a bug in the timer setting. It looks
>> like the iscsi layer has the right value (you wanted 2678400 right?),
>> but the timer layer may not be handling rollover correctly. Could you
>> possibly try a newer kernel just for testing? 2.6.16 is really old and
>> has other bugs.
>>
>> I will try this out on a current kernel and 2.6.16 to see if I can
>> replicate.
> > 


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

Re: Suggestion: creating a shared library

[Mike Christie]

Stefan de Konink wrote:
> Hi,
> 
> In the libvirt project we have stumbled upon a problem related to name
> changes of sys-fs. Looking at the Makefiles of open-iscsi and its
> usertools, I wonder if we can make it more easy for other projects using
> open-iscsi.
> 
> I propose to move the shared sourcecode of ISCSI_LIB_SRCS into a new
> shared object. Something like libopen-iscsi.so, in this way other projects
> can have consistent functions for example get_blockdev_from_lun.
> 
> 
> Is this an option?
> 

Are you going to make it? If so search through the list for others that 
were working on it so you can work together. I have got busy with other 
sutff so I have not been able to finish it. Hopefully after the offload 
card support is done I can get back to it if no one else is working on it.

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

Suggestion: creating a shared library

[Stefan de Konink]

Hi,

In the libvirt project we have stumbled upon a problem related to name
changes of sys-fs. Looking at the Makefiles of open-iscsi and its
usertools, I wonder if we can make it more easy for other projects using
open-iscsi.

I propose to move the shared sourcecode of ISCSI_LIB_SRCS into a new
shared object. Something like libopen-iscsi.so, in this way other projects
can have consistent functions for example get_blockdev_from_lun.


Is this an option?


Stefan


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

Re: iSCSI Timeout

[An Oneironaut]

Hey Mike,

I accidentally deleted my log so I can't give you anymore :-\.
But the error (1011) is there in the dump I sent.  I also have timed
the error and it looks like it takes about 20 to 21 seconds.  I have
also found a work around.  I changed my timeout time to 14
Days(1209600s) and the timeout seems to be working now.  Hope this
helps.

-JD

On May 14, 9:11 am, Mike Christie <[EMAIL PROTECTED]> wrote:
> An Oneironaut wrote:
> > I gave this a try but now when I set the timeout for a really long
> > period and disconnect my iSCSI device to test it, after about 2
> > minutes I get this:
>
> > <28>May 13 13:15:48 localhost iscsid: Kernel reported iSCSI connection
> > 4:0 error (1011) state (3)
> > <31>May 13 13:15:48 localhost iscsid: re-opening session 4 (reopen_cnt
> > 1)
> > <31>May 13 13:15:48 localhost iscsid: thread 0807e1cc delete: state 2
> > <31>May 13 13:15:48 localhost iscsid: in kstop_conn
> > <31>May 13 13:15:48 localhost iscsid: in __kipc_call
> > <31>May 13 13:15:48 localhost iscsid: in kwritev
> > <6>May 13 13:15:59 localhost kernel:  session4: iscsi: session
> > recovery timed out after 2678400 secs
>
> Could you send the part of the log where the error is detected (it would
> say something about iscsi connection error (1011)), so we know the
> timing better?
>
>
>
> > <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> > - not ready after error recovery
> > <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> > - not ready after error recovery
> > <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> > - not ready after error recovery
> > <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> > - not ready after error recovery
> > <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> > - not ready after error recovery
> > <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> > - not ready after error recovery
> > <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: SCSI error: return
> > code = 0x2
> > <4>May 13 13:15:59 localhost kernel: end_request: I/O error, dev sdb,
> > sector 75752
> > <3>May 13 13:15:59 localhost kernel: Buffer I/O error on device sdb,
> > logical block 9469
> > <4>May 13 13:15:59 localhost kernel: lost page write due to I/O error
> > on sdb
>
> > I am using an older version of open iscsi, Version 2.0-865.9.  Is this
> > why I am losing the connection before the time out period?
>
> I do not think so. It looks like a bug in the timer setting. It looks
> like the iscsi layer has the right value (you wanted 2678400 right?),
> but the timer layer may not be handling rollover correctly. Could you
> possibly try a newer kernel just for testing? 2.6.16 is really old and
> has other bugs.
>
> I will try this out on a current kernel and 2.6.16 to see if I can
> replicate.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Login retries on Wasabi target

[Albert Pauw]

Had to add the following line to kernel/Makefile:


linux_2_6_24: $(unpatch_code)


But still it won't compile:

/usr/src/redhat/BUILD/open-iscsi-2.0-865.15/kernel/
scsi_transport_iscsi.c:1529: error: too few arguments to function
‘netlink_kernel_create’

Any ideas?

Albert

On May 14, 5:55 pm, Mike Christie <[EMAIL PROTECTED]> wrote:
> Albert Pauw wrote:
> > Hi Mike,
>
> > I can't compile 865.15:
>
> > login.o: In function `resolve_address':
> > /usr/src/redhat/BUILD/open-iscsi-2.0-865.15/usr/login.c:168: warning:
> > Using 'getaddrinfo' in statically linked applications requires at
> > runtime the shared libraries from the glibc version used for linking
>
> That is just a warning. You can ignore since it is just for iscsistart too.
>
> > So I can't try that out. And yes, the firmware was updated as well. So
> > it is difficult for me to track it down.
> > Did you see any particular in the wireshark log?
>
> No, but I am still looking at it to try and line up changes with the
> iscsi_tcp changes.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: in /var/log/messages: conn errors and recovery

[a s p a s i a]

thanks for this final note/recommendation!  .. i will do so .. have
deployed the golden image though and so far my engineering users have
not complained seems like they are happy with their iscsi root on
CentoS!

- a.

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

Re: iSCSI Timeout

[Mike Christie]

An Oneironaut wrote:
> I gave this a try but now when I set the timeout for a really long
> period and disconnect my iSCSI device to test it, after about 2
> minutes I get this:
> 
> <28>May 13 13:15:48 localhost iscsid: Kernel reported iSCSI connection
> 4:0 error (1011) state (3)
> <31>May 13 13:15:48 localhost iscsid: re-opening session 4 (reopen_cnt
> 1)
> <31>May 13 13:15:48 localhost iscsid: thread 0807e1cc delete: state 2
> <31>May 13 13:15:48 localhost iscsid: in kstop_conn
> <31>May 13 13:15:48 localhost iscsid: in __kipc_call
> <31>May 13 13:15:48 localhost iscsid: in kwritev
> <6>May 13 13:15:59 localhost kernel:  session4: iscsi: session
> recovery timed out after 2678400 secs

Could you send the part of the log where the error is detected (it would 
say something about iscsi connection error (1011)), so we know the 
timing better?


> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> - not ready after error recovery
> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> - not ready after error recovery
> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> - not ready after error recovery
> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> - not ready after error recovery
> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> - not ready after error recovery
> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined
> - not ready after error recovery
> <6>May 13 13:15:59 localhost kernel: sd 4:0:0:0: SCSI error: return
> code = 0x2
> <4>May 13 13:15:59 localhost kernel: end_request: I/O error, dev sdb,
> sector 75752
> <3>May 13 13:15:59 localhost kernel: Buffer I/O error on device sdb,
> logical block 9469
> <4>May 13 13:15:59 localhost kernel: lost page write due to I/O error
> on sdb
> 
> I am using an older version of open iscsi, Version 2.0-865.9.  Is this
> why I am losing the connection before the time out period?
> 

I do not think so. It looks like a bug in the timer setting. It looks 
like the iscsi layer has the right value (you wanted 2678400 right?), 
but the timer layer may not be handling rollover correctly. Could you 
possibly try a newer kernel just for testing? 2.6.16 is really old and 
has other bugs.

I will try this out on a current kernel and 2.6.16 to see if I can 
replicate.

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

Re: Should connection restored?

[Mike Christie]

HIMANSHU wrote:
> 
> Hi..
> 
> It is probably not the problem of "replacement_timer".
> 

Did you try what I asked? Did you do the same timing in the tests?

In your log you had this:
session13: iscsi: session recovery timed out after 120 secs

When this is is printed out it means the replacment timer has fired and 
the devices will be unblocked (while they are blocked IO will be queued 
and will process will look like they are hung waiting for it) and IO 
will be failed until the session comes back.

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

Re: Login retries on Wasabi target

[Mike Christie]

Albert Pauw wrote:
> Hi Mike,
> 
> I can't compile 865.15:
> 
> login.o: In function `resolve_address':
> /usr/src/redhat/BUILD/open-iscsi-2.0-865.15/usr/login.c:168: warning:
> Using 'getaddrinfo' in statically linked applications requires at
> runtime the shared libraries from the glibc version used for linking
> 

That is just a warning. You can ignore since it is just for iscsistart too.

> So I can't try that out. And yes, the firmware was updated as well. So
> it is difficult for me to track it down.
> Did you see any particular in the wireshark log?
> 

No, but I am still looking at it to try and line up changes with the 
iscsi_tcp changes.

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

Re: crash at get_page_from_freelist() in iscsi start

[Mike Christie]

Or Gerlitz wrote:
> Hi Erez, Mike,
> 
> testing with 2.6.26-rc2 I get the below nice oops with iser but not with tcp 
> :(
> attached is my compressed .config, also I am using some derivative of 2.0-865,
> so I will move tomorrow to -869 but I wonder if you have any insight for
> this trace. The two warnings on the hwscan program don't seem very nice, 
> thoughts?
> 
> Or.
> 
> # iscsid -v
> iscsid version 2.0-865
> 
> # rpm -qi
> 
> rpm -qi open-iscsi
> Name: open-iscsi   Relocations: (not relocatable)
> Version : 2.0   Vendor: Voltaire Inc.
> Release : b4fae5f2fb14aaf7a92ff2f454c74081c552818c   Build Date: Tue Jan 
> 29 11:03:13 2008
> Install date: Tue Jan 29 11:04:58 2008  Build Host: dill.voltaire.com
> Group   : Productivity/Networking/Other   Source RPM: 
> open-iscsi-generic-2.0-b4fae5f2fb14aaf7a92ff2f454c74081c552818c.src.rpm
> Size: 5645667  License: GPL
> Signature   : (none)
> Packager: Erez Zilber <[EMAIL PROTECTED]>
> Summary : Linux* Open-iSCSI Software Initiator
> 
> 
> ib1: no IPv6 routers present
> Loading iSCSI transport class v2.0-869.
> iscsi: registered transport (tcp)
> iscsi: registered transport (iser)
> iser: iser_connect:connecting to: 192.168.10.55, port 0xbc0c
> iser: iser_cma_handler:event 0 conn 81001c91a4d0 id 81001c1340d8
> iser: iser_cma_handler:event 2 conn 81001c91a4d0 id 81001c1340d8
> iser: iser_create_ib_conn_res:setting conn 81001c91a4d0 cma_id 
> 81001c1340d8: fmr_pool 81002db6b470 qp 8100300a86e0
> iser: iser_cma_handler:event 9 conn 81001c91a4d0 id 81001c1340d8
> iser: iscsi_iser_ep_poll:ib conn 81001c91a4d0 rc = 1
> scsi0 : iSCSI Initiator over iSER, v.0.1
> iser: iscsi_iser_conn_bind:binding iscsi conn 810010c08f08 to iser_conn 
> 81001c91a4d0
> scsi 0:0:0:0: Direct-Access vendor   vendor DISK  v1.0 PQ: 0 ANSI: 4
> sd 0:0:0:0: [sda] 34789376 512-byte hardware sectors (17812 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 99 00 10 08
> sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO 
> and FUA
> sd 0:0:0:0: [sda] 34789376 512-byte hardware sectors (17812 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 99 00 10 08
> sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO 
> and FUA
>  sda: unknown partition table
> sd 0:0:0:0: [sda] Attached SCSI disk
> sd 0:0:0:0: Attached scsi generic sg0 type 0
> Program hwscan tried to access /dev/mem between f9000->10a000.
> program hwscan is using a deprecated SCSI ioctl, please convert it to SG_IO
> BUG: unable to handle kernel NULL pointer dereference at 0698
> IP: [] get_page_from_freelist+0x60/0x594
> PGD dd3b067 PUD 1c166067 PMD 0
> Oops:  [1] SMP
> CPU 1
> Modules linked in: ib_iser rdma_cm iw_cm ib_addr iscsi_tcp libiscsi 
> scsi_transport_iscsi ib_ipoib ib_cm ib_sa ipv6 sg st sd_mod sr_mod scsi_mod 
> ib_mthca ib_mad ib_core e100 i2c_amd756 i2c_amd8111 i2c_core
> Pid: 16520, comm: hwscan Not tainted 2.6.26-rc2 #3
> RIP: 0010:[]  [] 
> get_page_from_freelist+0x60/0x594
> RSP: 0018:81002f96d918  EFLAGS: 00010282
> RAX:  RBX:  RCX: 81002f96d970
> RDX:  RSI:  RDI: 810020002e68
> RBP: 000692d1 R08:  R09: 0044
> R10:  R11: 0246 R12: 810020002e48
> R13: 810020002e40 R14:  R15: 
> FS:  7f205a7054c0() GS:81003f917d58() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 0698 CR3: 12814000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
> Process hwscan (pid: 16520, threadinfo 81002f96c000, task 
> 81002b165100)
> Stack:   81002f96d948  
>   8022683d 0044 810020002e40
>   000612d180227482 0002 
> Call Trace:
>  [] ? __resched_task+0x64/0x66
>  [] ? __alloc_pages_internal+0xab/0x3cd
>  [] ? kmem_getpages+0x99/0x149
>  [] ? cache_grow+0x9c/0x33d
>  [] ? cache_alloc_refill+0x26d/0x2b9
>  [] ? sg_scsi_ioctl+0xd4/0x2e9
>  [] ? __kmalloc+0xe7/0x179
>  [] ? sg_scsi_ioctl+0xd4/0x2e9
>  [] ? :scsi_mod:scsi_request_fn+0x346/0x363
>  [] ? sync_page+0x0/0x45
>  [] ? scsi_cmd_ioctl+0x3a9/0x3ee
>  [] ? __lock_page+0x7d/0x83
>  [] ? wake_bit_function+0x0/0x23
>  [] ? add_to_page_cache+0x6f/0x84
>  [] ? wake_bit_function+0x0/0x23
>  [] ? poison_obj+0x35/0x43
>  [] ? cache_free_debugcheck+0x1e6/0x1f5
>  [] ? :sd_mod:sd_ioctl+0x95/0xc3
>  [] ? blkdev_driver_ioctl+0x54/0x66
>  [] ? blkdev_ioctl+0x744/0x75b
>  [] ? blkdev_open+0x0/0x5b
>  [] ? blkdev_open+0x2d/0x5b
>  [] ?

target*/*/block:change

[Stefan de Konink]

What was the reason for adding the block device name to the block symlink
if this symlink already provides this name?

It probably breaks everything that uses this block path directly to find
out the device it is pointing to.


Stefan


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

Re: Performance metrics on Open iSCSI project web site

[Pasi Kärkkäinen]

On Tue, May 13, 2008 at 09:01:24PM -0700, Dmitry Yusupov wrote:
> 
> This is results of disktest. Another example:
> 
> http://www.myri.com/scs/performance/Myri10GE/iSCSI/openiscsi.html
> 
> I recommend to take a look on disktest man page...
> 
> On Tue, 2008-05-13 at 18:51 -0500, Wesley Leggette wrote:
> > Hello,
> > 
> > I have a question regarding the performance metrics on the Open iSCSI
> > website.
> > 
> > Quoting:
> > 
> > 
> > single iSCSI session:
> > 
> > * 450MB/s Read and 450 MB/s Write for 64KB block
> > * 510 MB/s Read and 550 MB/s Write for 256KB block
> > * 65,000 IOPS - 1K, 58,000 IOPS - 2K, 50,000 IOPS with 4KB Read
> > 
> > (from http://www.open-iscsi.org/)
> > 
> > 
> > You mention a 64KB block. Do you refer to the device block size here?
> > What platform is this on? I was under the impression that on IA32
> > systems you could not have greater than a 4K block size, but is this a
> > device limit or is it only applicable when using a file system on top of
> > the device?

I'm pretty sure "64 kB block" refers to IO requests of size 64 kB were used..

-- Pasi

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