openiscsi 10gbe network
Hello, I'm writing in regards to the performance with open-iscsi on a 10gbe network. On your website you posted performance results indicating you reached read and write speeds of 450 MegaBytes per second. In our environment we use Myricom dual channel 10gbe network cards on a gentoo linux system connected via fiber to a 10gbe interfaced SAN with a raid 0 volume mounted with 4 15000rpm SAS drives. Unfortunately, the maximum speed we are acheiving is 94 MB/s. We do know that the network interfaces can stream data at 822MB/s (results obtained with netperf). we know that local read performance on the disks is 480MB/s. When using netcat or direct tcp/ip connection we get speeds in this range, however when we connect a volume via the iscsi protocol using the open-iscsi initiator we drop to 94MB/s(best result. Obtained with bonnie++ and dd). We were wondering if you would have any recommendations in terms of configuring the initiator or perhaps the linux system to achieve higher throughput. We have also set the the interfaces on both ends to jumbo frames (mtu 9000). We have also modified sysctl parameters to look as follows : net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.netdev_max_backlog = 25 Any help would greatly be appreciated, Thank you for your time and your work. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
!!!!Help: Problem when I login the iscsi hard disk
I use CentOS 5.3. When I login the iSCSI hard disk, it show the below information. I am confusing about this. Anyone can give me a help~~~Thanks~~~ iSCSI Target: Microsoft iSCSI Software Target iSCSI Initiator: iscsi-initiator-utils-6.2.0.871-0.10.el5 [r...@localhost /]# iscsiadm -m node -p 10.6.64.140 -l Logging in to [iface: default, target: iqn.1991-05.com.microsoft:wss- iscsi-test1-target, portal: 10.6.64.140,3260] Login to [iface: default, target: iqn.1991-05.com.microsoft:wss-iscsi- test1-target, portal: 10.6.64.140,3260]: successful Vendor: MSFT Model: Virtual HDRev: 3.2 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 41943040 512-byte hdwr sectors (21475 MB) sda: Write Protect is off sda: got wrong page sda: assuming drive cache: write through SCSI device sda: 41943040 512-byte hdwr sectors (21475 MB) sda: Write Protect is off sda: got wrong page sda: assuming drive cache: write through sd 6:0:0:0: Attached scsi disk sda sd 6:0:0:0: Attached scsi generic sg0 type 0 You have new mail in /var/spool/mail/root -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: help iscsi-initiator discovery
On Mon, Nov 23, 2009 at 05:31:06PM -0600, Mike Christie wrote: >xi qihao wrote: >>> What distro are you using? If you look in /dev/disk/by-id there should >>> be names that are persistent across reboots. >> >> It is CentOS (2.6.18-128.1.16.el5xen) x86_64 >> >> [r...@master ~]# ls -l /dev/disk/by-id/ >> total 0 >> lrwxrwxrwx 1 root root 9 Nov 20 11:00 >> scsi-SATA_WDC_WD800BD-22M_WD-WMAM9YU42742 -> ../../sda >> lrwxrwxrwx 1 root root 10 Nov 20 11:00 >> scsi-SATA_WDC_WD800BD-22M_WD-WMAM9YU42742-part1 -> ../../sda1 >> lrwxrwxrwx 1 root root 10 Nov 20 11:00 >> scsi-SATA_WDC_WD800BD-22M_WD-WMAM9YU42742-part2 -> ../../sda2 >> lrwxrwxrwx 1 root root 9 Nov 20 11:01 scsi-S_beaf11 -> ../../sdc >> lrwxrwxrwx 1 root root 10 Nov 20 11:01 scsi-S_beaf11-part1 -> ../../sdc1 >> lrwxrwxrwx 1 root root 9 Nov 20 11:01 scsi-S_beaf21 -> ../../sdb >> >> you mean scsi-S_beaf are persistent? >> > >Yes. I use multipath-tools to check the iscsi. It recognize beaf11 and beaf21. And configure a device map for it. Thanks! > >-- > >You received this message because you are subscribed to the Google Groups >"open-iscsi" group. >To post to this group, send email to open-is...@googlegroups.com. >To unsubscribe from this group, send email to >open-iscsi+unsubscr...@googlegroups.com. >For more options, visit this group at >http://groups.google.com/group/open-iscsi?hl=. > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [Patch 1/2] iscsiadm: login_portal() misses outputting logs for iscsid_req_by_rec()
Thanks for your patch. I tested your patch and it worked fine. So, next you will upload this patch to the git tree and the patch will become the part of source code in the next release of open-iscsi. Is my understanding correct? I am asking this question because I just want to know the normal development process of this and other linux project. 2009/11/24, Mike Christie : > Mike Christie wrote: >> Yangkook Kim wrote: >>> Hi, Mike. Thank you for your patch. >>> I do not want to add a login log message to the iscsid_req_* functions because they are generic and could be used for any operation. >>> Yes, that's perfectly right idea. That should be bettet than my patch. >>> >>> I tried your patch, but that still does not output login-success >>> message when calling >>> iscsid_req_by_rec. >>> >>> It seems that log_login_msg() would not be called in either >>> login_portal() or >>> iscsid_logout_reqs_wait() when iscsid_req_by_rec returns success. >>> >>> I probably missed something. I will look at it tomorrow again. >>> >> >> Nope. You are right. Nice catch. I messed up. I was only concentrating >> on the error paths. I will fix up my patch and resend. Thanks. >> > > > Here is a corrected patch. > > -- > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to open-is...@googlegroups.com. > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=. > > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH] do NOT perform illegal operations in a SIGSEGV handler
On 24 Nov 2009 at 13:20, guy keren wrote: [...] > by the way - if the system is set to generate core files for daemons, > then at least in theory it is possible to write some gdb macros that > will extract the non-flushed part of the logs from the core file - > assuming the shared-memory segment is still available. i need to check > if it's possible to make gdb re-attach to that segment while handling > the core file (generally this is not possible since you cannot run > function without attaching to a running process. however - there's a > project that allows re-creating a process around a core file - and > perhaps using that project this will become possible). > >From my eperience, it's much easier for users to find the last lines in a log file, rather than find a core dump file. Not to talk about corelating the core file with a program plus doing something useful with it. I a program I wrote years ago I did this: The log handler did flush the log whenever an error or more important had been output; it did not flush the log for debug messages or similar (I had fatal errors, errors, warnings, informational messages, and debug messages). Assuming that the program will crash only after some problem had been detected, this might help. Regards, Ulrich -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH] do NOT perform illegal operations in a SIGSEGV handler
Ulrich Windl wrote: > On 22 Nov 2009 at 13:50, guy keren wrote: > >> if you get SIGSEGV - most likely we have some memory ocrruption - so >> catching this signal, flushing the log and then returning (letting the >> process continue execution) is a big no-no. > > Well, > > depending on buffering, flushing the log may be a good idea. The question > whethet > it's safe to continue is a valid one, however. You could abort after that. > Maybe > it's better to ensure htat the logs are flushed frequent enough, so you don't > need > this. (I haven't checked) > > Ulrich The idea is that once your program receives a SEGV signal - you cannot be sure why it happened. it could have happened because the memory used by the logger contained a dangling pointer - and then trying to print the log from the SEGV handler could result an endless loop. the least you could do is set SIGSEGV to ignore before printing the log - although i am not sure that invoking a system call from within a signal handler is a good idea to begin with. by the way - if the system is set to generate core files for daemons, then at least in theory it is possible to write some gdb macros that will extract the non-flushed part of the logs from the core file - assuming the shared-memory segment is still available. i need to check if it's possible to make gdb re-attach to that segment while handling the core file (generally this is not possible since you cannot run function without attaching to a running process. however - there's a project that allows re-creating a process around a core file - and perhaps using that project this will become possible). --guy --guy -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
