Re: I/O Stall Patches
ByteEnable wrote: Hi Hannes, Mike. I've noticed that Hannes has been working a I/O stall issue and has created some patches. I'm curious because I'm seeing some I/O stall when I'm logged in to multiple targets. Is there a way to detect the signature of the I/O stall which Hannes is fixing? What type of stall are you seeing? In /var/log/messages do you see something about a iscsi nop/ping timing out, or do you see something about a target or host or lun reset succeeding/failing? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
transport classes vs binary interfaces
Hi, For the transport classes we have been providing a common interface to get transport specific values. For example, for all iscsi drivers we can get the target name in sysfs or for FC we can get the node name in a common place in sysfs. Or we can get transport events via the classes netlink APIs. For iscsi, We are now trying to support qla4xxx and be2iscsi (iscsi offload cards that are a little different from what we support today with bnx2i and cxgb3i) management. With qla4xxx you can do: 1. Just send a binary blob with configuration values between the card and userspace using a binary sysfs file or netlink. or 2. Extend the existing netlink and sysfs code so that the driver can get the rest of the values it needs in a format that makes sense for both drivers. With this we would add some netlink messages that are sent/received through the iscsi class netlink code. The new messages would have a bunch of iscsi or net or iscsi hba config values. Then the drivers would take those values or requests and do some mbox command to the card to get/set the config params. My question is there a preference or rule that says we should do #2? Or is doing #1 ok? In my opinion, #1 is very easy and would be the easiest route. However, anytime there is a format change I am relying on the vendor letting me know so I can update the iscsi tools. To some vendors the iscsi tools are secondary to their own tools, so I am not sure how much love I am going to get. If it is allowed though, I will not stop vendors from doing it. #2 is nice, because it makes it easier for any tools to manage any cards. --~--~-~--~~~---~--~~ 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: I/O Stall Patches
On Aug 26, 4:19 pm, Mike Christie micha...@cs.wisc.edu wrote: ByteEnable wrote: Hi Hannes, Mike. I've noticed that Hannes has been working a I/O stall issue and has created some patches. I'm curious because I'm seeing some I/O stall when I'm logged in to multiple targets. Is there a way to detect the signature of the I/O stall which Hannes is fixing? What type of stall are you seeing? In /var/log/messages do you see something about a iscsi nop/ping timing out, or do you see something about a target or host or lun reset succeeding/failing? I'm seeing ping time out's with an occasional tur failure from multipath which in turn kills the session on the path that fails. No TMF stuff. Byte --~--~-~--~~~---~--~~ 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: I/O Stall Patches
On 08/26/2009 07:58 PM, ByteEnable wrote: On Aug 26, 4:19 pm, Mike Christiemicha...@cs.wisc.edu wrote: ByteEnable wrote: Hi Hannes, Mike. I've noticed that Hannes has been working a I/O stall issue and has created some patches. I'm curious because I'm seeing some I/O stall when I'm logged in to multiple targets. Is there a way to detect the signature of the I/O stall which Hannes is fixing? What type of stall are you seeing? In /var/log/messages do you see something about a iscsi nop/ping timing out, or do you see something about a target or host or lun reset succeeding/failing? I'm seeing ping time out's with an occasional tur failure from multipath which in turn kills the session on the path that fails. No TMF stuff. What version of open-iscsi and what is the ping timeout? Could you try the kernel modules and tools from http://www.open-iscsi.org/bits/open-iscsi-2.0-871.tar.gz. I did a tiny change to the ping code, and it looks like for some other group it has fixed their problem (at least I have not heard back from them in a couple of weeks). --~--~-~--~~~---~--~~ 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: I/O Stall Patches
On Aug 26, 9:09 pm, Mike Christie micha...@cs.wisc.edu wrote: On 08/26/2009 07:58 PM, ByteEnable wrote: On Aug 26, 4:19 pm, Mike Christiemicha...@cs.wisc.edu wrote: ByteEnable wrote: Hi Hannes, Mike. I've noticed that Hannes has been working a I/O stall issue and has created some patches. I'm curious because I'm seeing some I/O stall when I'm logged in to multiple targets. Is there a way to detect the signature of the I/O stall which Hannes is fixing? What type of stall are you seeing? In /var/log/messages do you see something about a iscsi nop/ping timing out, or do you see something about a target or host or lun reset succeeding/failing? I'm seeing ping time out's with an occasional tur failure from multipath which in turn kills the session on the path that fails. No TMF stuff. What version of open-iscsi and what is the ping timeout? Could you try the kernel modules and tools fromhttp://www.open-iscsi.org/bits/open-iscsi-2.0-871.tar.gz. I did a tiny change to the ping code, and it looks like for some other group it has fixed their problem (at least I have not heard back from them in a couple of weeks). This is on RHEL5U4 first or so beta I believe. --~--~-~--~~~---~--~~ 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: I/O Stall Patches
On Aug 26, 9:20 pm, ByteEnable byteena...@gmail.com wrote: On Aug 26, 9:09 pm, Mike Christie micha...@cs.wisc.edu wrote: On 08/26/2009 07:58 PM, ByteEnable wrote: On Aug 26, 4:19 pm, Mike Christiemicha...@cs.wisc.edu wrote: ByteEnable wrote: Hi Hannes, Mike. I've noticed that Hannes has been working a I/O stall issue and has created some patches. I'm curious because I'm seeing some I/O stall when I'm logged in to multiple targets. Is there a way to detect the signature of the I/O stall which Hannes is fixing? What type of stall are you seeing? In /var/log/messages do you see something about a iscsi nop/ping timing out, or do you see something about a target or host or lun reset succeeding/failing? I'm seeing ping time out's with an occasional tur failure from multipath which in turn kills the session on the path that fails. No TMF stuff. What version of open-iscsi and what is the ping timeout? Could you try the kernel modules and tools fromhttp://www.open-iscsi.org/bits/open-iscsi-2.0-871.tar.gz. I did a tiny change to the ping code, and it looks like for some other group it has fixed their problem (at least I have not heard back from them in a couple of weeks). This is on RHEL5U4 first or so beta I believe. It's just a regular ping timeout. I'm not in front of the console but if I remember correctly its the standard timeouts set in iscsid.conf --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
