Re: Performance metrics on Open iSCSI project web site
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 -~--~~~~--~~--~--~---
Re: crash at get_page_from_freelist() in iscsi start
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: [8025a91a] 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:[8025a91a] [8025a91a] 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: [8022683d] ? __resched_task+0x64/0x66 [8025afaf] ? __alloc_pages_internal+0xab/0x3cd [802794f5] ? kmem_getpages+0x99/0x149 [80279952] ? cache_grow+0x9c/0x33d [80279e60] ? cache_alloc_refill+0x26d/0x2b9 [803217fd] ? sg_scsi_ioctl+0xd4/0x2e9 [8027a2fe] ? __kmalloc+0xe7/0x179 [803217fd] ? sg_scsi_ioctl+0xd4/0x2e9 [a0057b06] ? :scsi_mod:scsi_request_fn+0x346/0x363 [80255475] ? sync_page+0x0/0x45 [80321dbb] ? scsi_cmd_ioctl+0x3a9/0x3ee [80255464] ? __lock_page+0x7d/0x83 [802407cd] ? wake_bit_function+0x0/0x23 [802557a4] ? add_to_page_cache+0x6f/0x84 [802407cd] ? wake_bit_function+0x0/0x23 [80278306] ? poison_obj+0x35/0x43
Re: Should connection restored?
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: iSCSI Timeout
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: 28May 13 13:15:48 localhost iscsid: Kernel reported iSCSI connection 4:0 error (1011) state (3) 31May 13 13:15:48 localhost iscsid: re-opening session 4 (reopen_cnt 1) 31May 13 13:15:48 localhost iscsid: thread 0807e1cc delete: state 2 31May 13 13:15:48 localhost iscsid: in kstop_conn 31May 13 13:15:48 localhost iscsid: in __kipc_call 31May 13 13:15:48 localhost iscsid: in kwritev 6May 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? 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: SCSI error: return code = 0x2 4May 13 13:15:59 localhost kernel: end_request: I/O error, dev sdb, sector 75752 3May 13 13:15:59 localhost kernel: Buffer I/O error on device sdb, logical block 9469 4May 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: in /var/log/messages: conn errors and recovery
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: Login retries on Wasabi target
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: iSCSI Timeout
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: 28May 13 13:15:48 localhost iscsid: Kernel reported iSCSI connection 4:0 error (1011) state (3) 31May 13 13:15:48 localhost iscsid: re-opening session 4 (reopen_cnt 1) 31May 13 13:15:48 localhost iscsid: thread 0807e1cc delete: state 2 31May 13 13:15:48 localhost iscsid: in kstop_conn 31May 13 13:15:48 localhost iscsid: in __kipc_call 31May 13 13:15:48 localhost iscsid: in kwritev 6May 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? 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: SCSI error: return code = 0x2 4May 13 13:15:59 localhost kernel: end_request: I/O error, dev sdb, sector 75752 3May 13 13:15:59 localhost kernel: Buffer I/O error on device sdb, logical block 9469 4May 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
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 -~--~~~~--~~--~--~---
Feature: Support sysfs/firmware/ibft parsing.
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 http://www.gnu.org/licenses/. + */ + +#define _XOPEN_SOURCE 500 +#include
Re: target*/*/block:change
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 -~--~~~~--~~--~--~---
Maximum LUN support
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 -~--~~~~--~~--~--~---
