Re: ping timeouts
Ulrich Windl wrote: > Hmm, I wonder: If every packet exchange for an iSCSI target re-triggers a > timer > that prevents NOPs from being sent/expected, the problem under heavy load > should > go away as well, right? I see little sense to send extra NOP queries when > there is > heavy traffic for a target. (MHO) > But the point is there _is_ no traffic at that point. >> >> However, after some heavy instrumenting I found this: [ .. ] >> >> [ 2666.376858] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] >> delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 >> The 'cmd', 'mgmt', and 'req' parameters are just !list_empty(cmdqueue), !list_empty(mgmtqueue), !list_empty(requeue). (I said I'm running on an older code base). So at this point there are _no_ requests queued. Really curious. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: ping timeouts
Ulrich Windl wrote: > Hmm, I wonder: If every packet exchange for an iSCSI target re-triggers a > timer > that prevents NOPs from being sent/expected, the problem under heavy load > should > go away as well, right? I see little sense to send extra NOP queries when > there is > heavy traffic for a target. (MHO) > Ach, if it were so easy. Yes, of course you are correct. And yes, we shouldn't be sending NOPs when under high load. In fact I hooked into the tcp_data_ready() callback to make sure to update the timer whenever a new skb is available from the network stack. And even in any unterminated while() loop in the xmit and recv codepath. The problem is that I'm _still_ seeing the occasional nopouts. I did some analysis and printed the MIB statistics (ie octects send / received) when the NOP was being active. And it really _looks_ as if there is no traffic on this connection during that time. And what's more worrying, apparently we're sending a NOP and won't get a reply. I'm still fighting to get a wireshark trace; but dumping two _heavily_ loaded connections gives you massive traces. So far the disk space has run out before I got anything interesting noted in them :-( More updates to follow. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: undefined reference to strl* when building iscsid
On 20 Jul 2009 at 17:18, Evan Borgstrom wrote: > iscsid.c:437: warning: ignoring return value of 'chdir', declared with > attribute warn_unused_result > i Not ignoring the result of chdir() sounds like a good idea to me. ftruncate() is less likely to fail, and write() is somehwat in between I guess. 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-iscsi@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 -~--~~~~--~~--~--~---
Re: ping timeouts
Hmm, I wonder: If every packet exchange for an iSCSI target re-triggers a timer that prevents NOPs from being sent/expected, the problem under heavy load should go away as well, right? I see little sense to send extra NOP queries when there is heavy traffic for a target. (MHO) Regards, Ulrich On 20 Jul 2009 at 16:56, Hannes Reinecke wrote: > > Hi all, > > we do have a problem with NOP processing. Under heavy I/O, the connection > starts spitting out > 'ping timeout' error messages and resetting the connection. > There has been _no_ error from the target side nor the connection, so it's > us, sadly. > > However, after some heavy instrumenting I found this: > [ 2664.456270] connection2:0: Sending nopout exp 1913193 max 1913177 queued > 1913194 > > [ 2664.462592] connection2:0: mgmtpdu [itt xa05 p 8100795675c0] queued > > [ 2584.459166] connection2:0: mgmtpdu [op 0x0 hdr->itt 0xa05 datalen 0] > > [ 2584.466259] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] done > > [ 2585.232044] connection2:0: mgmtpdu [op 0x2 hdr->itt 0xa06 datalen 0] > > [ 2585.235410] connection2:0: mgmtpdu [itt 0xa06 p 810079567540] done > > [ 2666.376858] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] > delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 > > [ 2667.169094] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] > delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 > > [ 2667.179683] connection2:0: Sending nopout,cmd 0 mgmt 0 req 0 exp 1913193 > max 1913177 queued 1913194 > > [ 2669.092002] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] > delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 > > [ 2669.093935] connection2:0: ping timeout of 5 secs expired, stat > 7880612636/308802796/2 state 1/-150303960 > > [ 2669.097568] connection2:0: iscsi: detected conn error (1011) > > [ 2669.201246] session2: blocking session > > [ 2669.206148] connection2:0: mgmtpdu [itt xa05 p 8100795675c0] finished > > > (ignore the clock skew, it's a multicore TSC problem ...). > > The numbers are ExpCmdSN, MaxCmdSN, and queued CmdSN. > So, as you can see, we're for some reason sending a NOP-Out with CmdSN > 1913194, ExpCmdSN 1913193, and MaxCmdSN 191377. > But reading through RFC 3720, I found this: > >The target MUST NOT transmit a MaxCmdSN that is less than >ExpCmdSN-1. For non-immediate commands, the CmdSN field can take any >value from ExpCmdSN to MaxCmdSN inclusive. The target MUST silently >ignore any non-immediate command outside of this range or non- >immediate duplicates within the range. The CmdSN carried by >immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. >For example, if the initiator has previously sent a non-immediate >command carrying the CmdSN equal to MaxCmdSN, the target window is >closed. For group task management commands issued as immediate >commands, CmdSN indicates the scope of the group action (e.g., on >ABORT TASK SET indicates which commands are aborted). > > So no wonder we're never seeing any replies to that one. > > Question remains, though, why we're starting to send PDUs with invalid > MaxCmdSN numbers ... > > Apologies as I'm running on an older codebase. But the same error / > 'behaviour' > is present in mainline as well. > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke zSeries & Storage > h...@suse.de+49 911 74053 688 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: Markus Rex, HRB 16746 (AG Nürnberg) > > > --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
undefined reference to strl* when building iscsid
Hi, I'm trying to build open-iscsi-2.0-871 on Gentoo (Kernel 2.6.30 with OpenSUSE Xen patches / GCC 4.3.3 / glibc 2.9). The kernel modules build fine but when trying to build iscsid I get the following errors: cc -O2 -g -Wall -Wstrict-prototypes -I../include -I. -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsid.o iscsid.c iscsid.c: In function 'main': iscsid.c:437: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result iscsid.c:443: warning: ignoring return value of 'ftruncate', declared with attribute warn_unused_result iscsid.c:445: warning: ignoring return value of 'write', declared with attribute warn_unused_result cc -O2 -g -Wall -Wstrict-prototypes -I../include -I. -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o host.o session_info.o iscsi_sysfs.o netlink.o initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o isns.o cxgb3i.o transport.o iscsid.o -o iscsid io.o: In function `get_netdev_from_hwaddress': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/io.c:189: undefined reference to `strlcpy' io.o: In function `bind_conn_to_iface': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/io.c:211: undefined reference to `strlcpy' /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/io.c:293: undefined reference to `strlcpy' auth.o: In function `acl_set_key_value': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:554: undefined reference to `strlcpy' auth.o: In function `acl_set_user_name': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:1895: undefined reference to `strlcpy' auth.o:/var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open- iscsi-2.0-871/usr/auth.c:1527: more undefined references to `strlcpy' follow auth.o: In function `acl_set_key': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:648: undefined reference to `strlcat' /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:650: undefined reference to `strlcat' auth.o: In function `acl_set_chap_alg_key': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:750: undefined reference to `strlcpy' /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:753: undefined reference to `strlcat' /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:755: undefined reference to `strlcat' The full output of the build is available here: http://pastie.org/552382.txt Does anyone have any guidance on how to fix this? Thanks. -E P.S. Sorry if this posted twice, I sent a message through this morning that didn't show up on the group page. --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
undefined reference to `strlcpy' when building iscsid
Hi, I'm trying to build open-iscsi-2.0-871 on Gentoo (Kernel 2.6.30 with OpenSUSE Xen patches / GCC 4.3.3 / glibc 2.9). The kernel modules build fine but when trying to build iscsid I get the following errors: c -O2 -g -Wall -Wstrict-prototypes -I../include -I. -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o host.o session_info.o iscsi_sysfs.o netlink.o initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o isns.o cxgb3i.o transport.o iscsid.o -o iscsid io.o: In function `get_netdev_from_hwaddress': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/io.c:189: undefined reference to `strlcpy' io.o: In function `bind_conn_to_iface': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/io.c:211: undefined reference to `strlcpy' /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/io.c:293: undefined reference to `strlcpy' auth.o: In function `acl_set_key_value': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:554: undefined reference to `strlcpy' auth.o: In function `acl_set_user_name': /var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open-iscsi-2.0-871/ usr/auth.c:1895: undefined reference to `strlcpy' auth.o:/var/tmp/portage/sys-block/open-iscsi-2.0.871/work/open- iscsi-2.0-871/usr/auth.c:1527: more undefined references to `strlcpy' follow The full output of the build is available here: http://pastie.org/552382 Does anyone have any guidance on how to fix this? Thanks. -E --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: How does readahead(2) affects a iscsi device
Hello Konrad, > On Fri, Jul 03, 2009 at 04:10:19PM +0200, Maddin wrote: > >> Hi folks, >> >> Sorry but not so firm in kernel hacking and structures, but if I've >> understood this correctly it should perform normally?! >> The problem is that I do a readahead (the tool) on a iscsi device with >> infortrend iscsi san as backend to warm up caches and my connection died, >> correctly the whole controller died and have to be reseted. >> > > Whoa! Have you filled a ticket with them? > Yes sir, ticket is opened. But unfortunately they can't reproduce the whole bahvior. At their tests, the nic was stopping answering on pings, and now this ticket was escalated to 2nd level support. Now i have to wait. >> Has anyone an idea? >> > > Sounds like a big bug in their product. > >> Cheers >> Maddin >> --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: ping timeouts
On 07/20/2009 12:16 PM, Mike Christie wrote: > hdr->cmd_sn = session->cmdsn++; > so after we send a hdr with the cmdsn we incremented the session Not send. I meant to write prepd above. > tracking one and so the tracking one is going to be one higher than what > we are actually sending. > --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: ping timeouts
On 07/20/2009 09:56 AM, Hannes Reinecke wrote: > Hi all, > > we do have a problem with NOP processing. Under heavy I/O, the connection > starts spitting out > 'ping timeout' error messages and resetting the connection. > There has been _no_ error from the target side nor the connection, so it's > us, sadly. > > However, after some heavy instrumenting I found this: > [ 2664.456270] connection2:0: Sending nopout exp 1913193 max 1913177 queued > 1913194 > > [ 2664.462592] connection2:0: mgmtpdu [itt xa05 p 8100795675c0] queued > > [ 2584.459166] connection2:0: mgmtpdu [op 0x0 hdr->itt 0xa05 datalen 0] > > [ 2584.466259] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] done > > [ 2585.232044] connection2:0: mgmtpdu [op 0x2 hdr->itt 0xa06 datalen 0] > > [ 2585.235410] connection2:0: mgmtpdu [itt 0xa06 p 810079567540] done > > [ 2666.376858] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] > delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 > > [ 2667.169094] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] > delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 > > [ 2667.179683] connection2:0: Sending nopout,cmd 0 mgmt 0 req 0 exp 1913193 > max 1913177 queued 1913194 > > [ 2669.092002] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] > delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 > > [ 2669.093935] connection2:0: ping timeout of 5 secs expired, stat > 7880612636/308802796/2 state 1/-150303960 > > [ 2669.097568] connection2:0: iscsi: detected conn error (1011) > > [ 2669.201246] session2: blocking session > > [ 2669.206148] connection2:0: mgmtpdu [itt xa05 p 8100795675c0] finished > > > (ignore the clock skew, it's a multicore TSC problem ...). > > The numbers are ExpCmdSN, MaxCmdSN, and queued CmdSN. > So, as you can see, we're for some reason sending a NOP-Out with CmdSN > 1913194, ExpCmdSN 1913193, and MaxCmdSN 191377. For queued CmdSn, are you printing out the session->queued_cmdsn or session->cmdsn? You probably want the session->cmdsn. The queued one is just internal. Actually you probably want to print out the hdr->cmdsn that is set in the prep functions, and you want to print it out the sn numbers right before the hdr is sent out in iscsi_xmit_task. If you are printing out the session->*cmdsn then we do this hdr->cmd_sn = session->cmdsn++; so after we send a hdr with the cmdsn we incremented the session tracking one and so the tracking one is going to be one higher than what we are actually sending. Where are you printing those values? You would want to print them from iscsi_data_xmit after they task has been prepd. > But reading through RFC 3720, I found this: > > The target MUST NOT transmit a MaxCmdSN that is less than > ExpCmdSN-1. For non-immediate commands, the CmdSN field can take any > value from ExpCmdSN to MaxCmdSN inclusive. The target MUST silently > ignore any non-immediate command outside of this range or non- > immediate duplicates within the range. The CmdSN carried by > immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. > For example, if the initiator has previously sent a non-immediate > command carrying the CmdSN equal to MaxCmdSN, the target window is > closed. For group task management commands issued as immediate > commands, CmdSN indicates the scope of the group action (e.g., on > ABORT TASK SET indicates which commands are aborted). > > So no wonder we're never seeing any replies to that one. > > Question remains, though, why we're starting to send PDUs with invalid > MaxCmdSN numbers ... > Have you run in a wireshark trace to check if we are getting bad maxcmdsns from the target? libiscsi only copies it from the pdu, so maybe in iscsi_update_cmdsn() we are not copying MaxCmdSN when we should be or maybe the target is sending us bad values. --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: How does readahead(2) affects a iscsi device
On Fri, Jul 03, 2009 at 04:10:19PM +0200, Maddin wrote: > > Hi folks, > > Sorry but not so firm in kernel hacking and structures, but if I've > understood this correctly it should perform normally?! > The problem is that I do a readahead (the tool) on a iscsi device with > infortrend iscsi san as backend to warm up caches and my connection died, > correctly the whole controller died and have to be reseted. Whoa! Have you filled a ticket with them? > > Has anyone an idea? Sounds like a big bug in their product. > > Cheers > Maddin > > > > > > --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
ping timeouts
Hi all, we do have a problem with NOP processing. Under heavy I/O, the connection starts spitting out 'ping timeout' error messages and resetting the connection. There has been _no_ error from the target side nor the connection, so it's us, sadly. However, after some heavy instrumenting I found this: [ 2664.456270] connection2:0: Sending nopout exp 1913193 max 1913177 queued 1913194 [ 2664.462592] connection2:0: mgmtpdu [itt xa05 p 8100795675c0] queued [ 2584.459166] connection2:0: mgmtpdu [op 0x0 hdr->itt 0xa05 datalen 0] [ 2584.466259] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] done [ 2585.232044] connection2:0: mgmtpdu [op 0x2 hdr->itt 0xa06 datalen 0] [ 2585.235410] connection2:0: mgmtpdu [itt 0xa06 p 810079567540] done [ 2666.376858] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 [ 2667.169094] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 [ 2667.179683] connection2:0: Sending nopout,cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 [ 2669.092002] connection2:0: mgmtpdu [itt 0xa05 p 8100795675c0] delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194 [ 2669.093935] connection2:0: ping timeout of 5 secs expired, stat 7880612636/308802796/2 state 1/-150303960 [ 2669.097568] connection2:0: iscsi: detected conn error (1011) [ 2669.201246] session2: blocking session [ 2669.206148] connection2:0: mgmtpdu [itt xa05 p 8100795675c0] finished (ignore the clock skew, it's a multicore TSC problem ...). The numbers are ExpCmdSN, MaxCmdSN, and queued CmdSN. So, as you can see, we're for some reason sending a NOP-Out with CmdSN 1913194, ExpCmdSN 1913193, and MaxCmdSN 191377. But reading through RFC 3720, I found this: The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1. For non-immediate commands, the CmdSN field can take any value from ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any non-immediate command outside of this range or non- immediate duplicates within the range. The CmdSN carried by immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. For example, if the initiator has previously sent a non-immediate command carrying the CmdSN equal to MaxCmdSN, the target window is closed. For group task management commands issued as immediate commands, CmdSN indicates the scope of the group action (e.g., on ABORT TASK SET indicates which commands are aborted). So no wonder we're never seeing any replies to that one. Question remains, though, why we're starting to send PDUs with invalid MaxCmdSN numbers ... Apologies as I'm running on an older codebase. But the same error / 'behaviour' is present in mainline as well. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Error while backing up mulitpath devices using CDP
> If you set the values to 0 you should not get the ping timeout error > message. When you use that value do you see: > > Jun 23 12:21:24 mss-us2 kernel: connection8:0: ping timeout of 5 secs > expired, last rx 7739207452, last ping 7739212452, now 7739217452 > > If you do then run > > iscsidm -m node -T your_tagret -p your_portal | grep noop > > and make sure those values are 0. Hi Mike, Thanks for your help. node.conn[0].timeo.noop_out_* value to 0 made the backup worked -Jeetendra --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
