Re: Failover time of iSCSI multipath devices.
Mike Christie wrote: On 03/15/2010 05:56 AM, Alex Zeffertt wrote: The bugzilla ticket requests a merge of two git commits, but neither of those contain the libiscsi.c change that addresses bug #2. Was this a mistake, or did you deliberately omit that part of your speed-up-conn-fail-take3.patch when you raised the ticket? Hey, It was laziness. I did not update the bugzilla. When I made it, I thought we were only hitting #1 (this was the first patch I sent in this thread). But when I was testing those 2 patches with RHEL 5, I finally hit the problem that bet was hitting. When I figured out that we were hitting #2, I made the second patch in this thread. I then just did not update the bugzilla with the new patch. For RHEL I ended up sending the second patch though. Thanks for the clarification. Is the fix for #2 being upstreamed? If so, is there a git commit I can reference? (This will make it easier for us to drop the patch when we pull a kernel which has the fix in it.) Thanks in advance, Alex -- 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.
iSNS implementation
Hi All, Can someone explain about what is the usage of this print_scn_pdu() function defined in isns.c file. Thanks Gopal. -- 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.
Understanding iscsi kernel space codes
Hi, all. I'm now trying to study open-iscsi kernel space codes. Basically my goal is understanding how iscsi packet is created/sent/recieved in kernel space. Unlike user space codes, there is no main function, so not sure about where I should start from. There are four kernel codes files. iscsi_tcp.c libiscsi.c libiscsi_tcp.c scsi_transport_iscsi.c Can anybody tell me which file is a good start point to understand iscsi code flow in kernel space? Also, can anybody briefly tell me the main functions of each file above? Thanks, Kim -- 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: Understanding iscsi kernel space codes
iscsi_tcp.c if you are not a scsi guy already. Other wise scsi_transport.cGood luck.. On Tue, Mar 16, 2010 at 8:52 PM, Yangkook Kim yangkook...@gmail.com wrote: Hi, all. I'm now trying to study open-iscsi kernel space codes. Basically my goal is understanding how iscsi packet is created/sent/recieved in kernel space. Unlike user space codes, there is no main function, so not sure about where I should start from. There are four kernel codes files. iscsi_tcp.c libiscsi.c libiscsi_tcp.c scsi_transport_iscsi.c Can anybody tell me which file is a good start point to understand iscsi code flow in kernel space? Also, can anybody briefly tell me the main functions of each file above? Thanks, Kim -- 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. -- 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: [Iscsitarget-devel] iSNS implementation
On Mar 16, 2010, at 9:24 AM, Gopu Krishnan gopu.0...@gmail.com wrote: Hi All, Can someone explain about what is the usage of this print_scn_pdu () function defined in isns.c file. You have the source code in front of you why don't you explain to me what it does and if you see a problem point it out (CC the author of that code too). -Ross __ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. -- 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.
x86 vs x86_64 and iSCSI
Hello, We are buying some recent 64-bit capable machines to serve as iSCSI backends to a file-server. I was wondering whether somebody has input on which architecture x86 or x86_64 we should use for our iSCSI backends if we use the open- iscsi driver? Does it matter at all? What are some factors that come into play here? For example: 1) Does memory performance differ and matter? 2) Is there any effect on disk performance? 3) What about network performance? 4) Which architecture are most open-iscsi users adopting (this would potentially speed bug detection and resolution)? Is anybody aware of any benchmarks that compare 32-bit vs 64-bit performance with open-iscsi? Thanks! Iordan Iordanov -- 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: Failover time of iSCSI multipath devices.
On 03/16/2010 04:50 AM, Alex Zeffertt wrote: Mike Christie wrote: On 03/15/2010 05:56 AM, Alex Zeffertt wrote: The bugzilla ticket requests a merge of two git commits, but neither of those contain the libiscsi.c change that addresses bug #2. Was this a mistake, or did you deliberately omit that part of your speed-up-conn-fail-take3.patch when you raised the ticket? Hey, It was laziness. I did not update the bugzilla. When I made it, I thought we were only hitting #1 (this was the first patch I sent in this thread). But when I was testing those 2 patches with RHEL 5, I finally hit the problem that bet was hitting. When I figured out that we were hitting #2, I made the second patch in this thread. I then just did not update the bugzilla with the new patch. For RHEL I ended up sending the second patch though. Thanks for the clarification. Is the fix for #2 being upstreamed? If so, I sent it to linux-scsi/James a couple days after I sent the patch in this thread. It is not merged yet. is there a git commit I can reference? (This will make it easier for us to drop the patch when we pull a kernel which has the fix in it.) Do you want me to cc you on all future iscsi patches that go upstream? When James merges it and sends it to linus, then I get a automated message from him. If I cc you, you can get one too. Thanks in advance, Alex -- 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: Failover time of iSCSI multipath devices.
I am trying work out a formula for total failover time of my multipathed iSCSI device so far I have: failover time = nop timout + nop interval + replacement_timeout seconds + scsi block device timeout(/sys/block/sdX/device/timeout) Is there anything else that I am missing? -b On Mar 15, 4:53 pm, Mike Christie micha...@cs.wisc.edu wrote: On 03/15/2010 05:56 AM, Alex Zeffertt wrote: The bugzilla ticket requests a merge of two git commits, but neither of those contain the libiscsi.c change that addresses bug #2. Was this a mistake, or did you deliberately omit that part of your speed-up-conn-fail-take3.patch when you raised the ticket? Hey, It was laziness. I did not update the bugzilla. When I made it, I thought we were only hitting #1 (this was the first patch I sent in this thread). But when I was testing those 2 patches with RHEL 5, I finally hit the problem that bet was hitting. When I figured out that we were hitting #2, I made the second patch in this thread. I then just did not update the bugzilla with the new patch. For RHEL I ended up sending the second patch though. -- 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: Failover time of iSCSI multipath devices.
On 03/16/2010 04:02 PM, bennyturns wrote: I am trying work out a formula for total failover time of my multipathed iSCSI device so far I have: failover time = nop timout + nop interval + replacement_timeout seconds + scsi block device timeout(/sys/block/sdX/device/timeout) /sys/block/sdX/device/timeout is the scsi cmd timeout. It only comes into play if you have nops off or have their timers set higher than the scsi cmd timeout (you do not want to do this). When using nops if they timeout then if the scsi cmd timer fires, the iscsi code would basically tell the scsi layer they it is handling the problem so do not run the scsi error handler. So it is: failover time = nop timout + nop interval + replacement_timeout or /sys/block/sdX/device/timeout + replacement_timeout + min(abort, lun reset timeoutt, target reset timeout). Is there anything else that I am missing? -b On Mar 15, 4:53 pm, Mike Christiemicha...@cs.wisc.edu wrote: On 03/15/2010 05:56 AM, Alex Zeffertt wrote: The bugzilla ticket requests a merge of two git commits, but neither of those contain the libiscsi.c change that addresses bug #2. Was this a mistake, or did you deliberately omit that part of your speed-up-conn-fail-take3.patch when you raised the ticket? Hey, It was laziness. I did not update the bugzilla. When I made it, I thought we were only hitting #1 (this was the first patch I sent in this thread). But when I was testing those 2 patches with RHEL 5, I finally hit the problem that bet was hitting. When I figured out that we were hitting #2, I made the second patch in this thread. I then just did not update the bugzilla with the new patch. For RHEL I ended up sending the second patch though. -- 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: Failover time of iSCSI multipath devices.
Thks Mike, that explains it :) On Mar 16, 5:27 pm, Mike Christie micha...@cs.wisc.edu wrote: On 03/16/2010 04:02 PM, bennyturns wrote: I am trying work out a formula for total failover time of my multipathed iSCSI device so far I have: failover time = nop timout + nop interval + replacement_timeout seconds + scsi block device timeout(/sys/block/sdX/device/timeout) /sys/block/sdX/device/timeout is the scsi cmd timeout. It only comes into play if you have nops off or have their timers set higher than the scsi cmd timeout (you do not want to do this). When using nops if they timeout then if the scsi cmd timer fires, the iscsi code would basically tell the scsi layer they it is handling the problem so do not run the scsi error handler. So it is: failover time = nop timout + nop interval + replacement_timeout or /sys/block/sdX/device/timeout + replacement_timeout + min(abort, lun reset timeoutt, target reset timeout). Is there anything else that I am missing? -b On Mar 15, 4:53 pm, Mike Christiemicha...@cs.wisc.edu wrote: On 03/15/2010 05:56 AM, Alex Zeffertt wrote: The bugzilla ticket requests a merge of two git commits, but neither of those contain the libiscsi.c change that addresses bug #2. Was this a mistake, or did you deliberately omit that part of your speed-up-conn-fail-take3.patch when you raised the ticket? Hey, It was laziness. I did not update the bugzilla. When I made it, I thought we were only hitting #1 (this was the first patch I sent in this thread). But when I was testing those 2 patches with RHEL 5, I finally hit the problem that bet was hitting. When I figured out that we were hitting #2, I made the second patch in this thread. I then just did not update the bugzilla with the new patch. For RHEL I ended up sending the second patch though. -- 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.
