Re: Antw: open-iscsi /w suspend to ram / resume.
On 10/30/2011 08:01 AM, Vincent Pelletier wrote: On Dec 7 2010, 11:12 pm, Mike Christie micha...@cs.wisc.edu wrote: It could, but you should be ok. If the notification that the connection is dead comes after IO is sent then we would try to send IO to the network layer, but the iscsi layer would eventually figure things out and end up resending the IO after it has reconnected to the target. Hi list (my first post here). I'm an iscsi noob (just bought a cheap NAS) and just succeeded in moving an existing Debian install to a diskless, PXE root-on-iscsi setup. It works fine, except for the subject of this thread: when resuming from ram suspend (and probably after waiting long enough in suspend, I haven't done many tries so far), resume is stuck for 120s ( node.session.timeo.replacement_timeout is set to 120s by default, maybe this is the timeout I encounter), then a reconnection occurs and resume finishes successfully. Though not without emitting a handful of kernel BUGs (soft lockup - CPU#0 stuck for 22s). Are these coming from accesses to the iscsi disk that is root? If so when the replacement timeout fires, do you get IO errors for the root paritition or are you using something like multipath over iscsi (I see you have only one path but are you using it to just temporarily queue IO)? Could you send the /var/log/messages? For the moment, I don't have an idea on how to make resume happen gracefully: - Shorten this timeout ? But for what risks ? Network setup is dead-simple: Gb ethernet with one switch and a few meters of cable. - I found a dmsetup suspend command, but I'm not sure I want to run this on a root device... - Get some script to be cached before suspend and executed early upon resume ? -- 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?hl=en.
Re: Antw: open-iscsi /w suspend to ram / resume.
On Dec 7 2010, 11:12 pm, Mike Christie micha...@cs.wisc.edu wrote: It could, but you should be ok. If the notification that the connection is dead comes after IO is sent then we would try to send IO to the network layer, but the iscsi layer would eventually figure things out and end up resending the IO after it has reconnected to the target. Hi list (my first post here). I'm an iscsi noob (just bought a cheap NAS) and just succeeded in moving an existing Debian install to a diskless, PXE root-on-iscsi setup. It works fine, except for the subject of this thread: when resuming from ram suspend (and probably after waiting long enough in suspend, I haven't done many tries so far), resume is stuck for 120s ( node.session.timeo.replacement_timeout is set to 120s by default, maybe this is the timeout I encounter), then a reconnection occurs and resume finishes successfully. Though not without emitting a handful of kernel BUGs (soft lockup - CPU#0 stuck for 22s). For the moment, I don't have an idea on how to make resume happen gracefully: - Shorten this timeout ? But for what risks ? Network setup is dead-simple: Gb ethernet with one switch and a few meters of cable. - I found a dmsetup suspend command, but I'm not sure I want to run this on a root device... - Get some script to be cached before suspend and executed early upon resume ? Any pointer welcome. Regards, -- Vincent Pelletier -- 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?hl=en.
Re: Antw: open-iscsi /w suspend to ram / resume.
Hi. A short update first: I don't have this problem on any later suspend attempt (~4 so far, from a few dozen of minutes suspend to several hours). And a disclaimer: my kernel is tainted. Nvidia proprietary driver. Yuck. Feel free to blame the problems on it, I need a motivation to switch this box to nouveau ;) . On Mon, Oct 31, 2011 at 7:07 PM, Mike Christie micha...@cs.wisc.edu wrote: Are these coming from accesses to the iscsi disk that is root? If so when the replacement timeout fires, do you get IO errors for the root paritition or are you using something like multipath over iscsi (I see you have only one path but are you using it to just temporarily queue IO)? I don't use multipath (...at least, if lsmod | grep multipath - nothing is enough to tell I'm not). I've not configured a thing to use it. Could you send the /var/log/messages? Attached (gzipped, as it's 250k+ extracted). Limited from boot to shutdown (...for reboot). Weird enough: last lines before suspend have a timestamp from wakeup time. Also, the error output from wakeup is truncated, as seen on line 670: Oct 30 06:23:22 localhost kernel: [ 1138.769133] Restarting tasks ... 95606] [8100a9ef] ? do_softirq+0x3f/0x84 Note: I accidentally hit ctrl-scroll lock while trying to make console flood stop to get time to read - and discovered it somehow dumped scheduler status. Sorry for the data it pushed out of buffer. For the moment, I don't have an idea on how to make resume happen gracefully: A note on my setup for that boot: actually, I wasn't completely netbooting at that point: grub2 /boot were on local disk, but initrd was initiating iscsi connection. It was an intermediate setting, and I am now completely booting off iscsi (+ TFTP): BIOS + embedded PXE (because I don't want to reflash) - iPXE (sanboot iscsi:... maps iscsi to bios disk 0x80) - grub2 - linux - initrd reconnects to iscsi to mount / Maybe this could explain the problem I had (maybe the kernel/suspend tools weren't treating network gently enough for a clean resume). Regards, -- Vincent Pelletier -- 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?hl=en. messages.gz Description: GNU Zip compressed data
how default interface works
hi, I want to know ,when we didn't login using -I iface ,then how default interface figure out which interface to use to connect. please explain. thanks vipul vaid -- 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?hl=en.
Discovery of iSCSI communication on a switch.
Hi, I develop s/w for a switch. I would like to discover iSCSI sessions that pass through my switch. For this I feel that it is not enough to snoop on just TCP-SYN messages. According to me, TCP-SYN messages are sent during TCP- Session establishment. I feel that I should snoop on 0X03 iSCSI-LogIn messages. Can anybody confirm this please. Thanks, Sita. -- 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?hl=en.
Re: Discovery of iSCSI communication on a switch.
On 10/31/2011 05:10 AM, Sita Allamudi wrote: Hi, I develop s/w for a switch. I would like to discover iSCSI sessions that pass through my switch. For this I feel that it is not enough to snoop on just TCP-SYN messages. According to me, TCP-SYN messages are sent during TCP- Session establishment. I feel that I should snoop on 0X03 iSCSI-LogIn messages. Can anybody confirm this please. Why does your switch need to look at iscsi stuff? Is it going to be doing some sort of optimizations when it knows it is a iscsi connection? Just wondering. Other stuff would do the normal tcp syn ack stuff for connection creation so I think you have to look for the iscsi login messages and not just the tcp/ip connection ones. -- 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?hl=en.
Re: how default interface works
On 10/31/2011 08:15 AM, vipul vaid wrote: hi, I want to know ,when we didn't login using -I iface ,then how default interface figure out which interface to use to connect. please explain. It depends. It will log into all sessions that are using the default iface for that portal. Or if you have ifaces that use tcp for the transport then it would also log into those. -- 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?hl=en.
Re: Antw: open-iscsi /w suspend to ram / resume.
On 10/31/2011 03:26 PM, Vincent Pelletier wrote: Hi. A short update first: I don't have this problem on any later suspend attempt (~4 so far, from a few dozen of minutes suspend to several hours). And a disclaimer: my kernel is tainted. Nvidia proprietary driver. Yuck. Feel free to blame the problems on it, I need a motivation to switch this box to nouveau ;) . On Mon, Oct 31, 2011 at 7:07 PM, Mike Christie micha...@cs.wisc.edu wrote: Are these coming from accesses to the iscsi disk that is root? If so when the replacement timeout fires, do you get IO errors for the root paritition or are you using something like multipath over iscsi (I see you have only one path but are you using it to just temporarily queue IO)? I don't use multipath (...at least, if lsmod | grep multipath - nothing is enough to tell I'm not). I've not configured a thing to use it. Could you send the /var/log/messages? Attached (gzipped, as it's 250k+ extracted). Limited from boot to shutdown (...for reboot). Weird enough: last lines before suspend have a timestamp from wakeup time. Also, the error output from wakeup is truncated, as seen on line 670: Oct 30 06:23:22 localhost kernel: [ 1138.769133] Restarting tasks ... 95606] [8100a9ef] ? do_softirq+0x3f/0x84 Is the log you attached of the case where it took hours or one where it now sort of works? I did not see the 120 sec issue or any soft lockups. When you hit the problem is the network accessible and is iscsid up and running? Can you ping the initiator box from another box on the network? When you said then a reconnection occurs what did you mean? Did you see a iscsi message indicating that we were reconnected to the target? Note: I accidentally hit ctrl-scroll lock while trying to make console flood stop to get time to read - and discovered it somehow dumped scheduler status. Sorry for the data it pushed out of buffer. For the moment, I don't have an idea on how to make resume happen gracefully: A note on my setup for that boot: actually, I wasn't completely netbooting at that point: grub2 /boot were on local disk, but initrd was initiating iscsi connection. It was an intermediate setting, and I am now completely booting off iscsi (+ TFTP): BIOS + embedded PXE (because I don't want to reflash) - iPXE (sanboot iscsi:... maps iscsi to bios disk 0x80) - grub2 - linux - initrd reconnects to iscsi to mount / Maybe this could explain the problem I had (maybe the kernel/suspend tools weren't treating network gently enough for a clean resume). You are doing the suspend after we have povited from the initramfs to the real /, right? If so that should not be an issue. -- 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?hl=en.
