Re: mc/s - not yet in open-iscsi?
Christopher Barry, on 06/10/2010 03:09 AM wrote: Greetings everyone, Had a question about implementing mc/s using open-iscsi today. Wasn't really sure exactly what it was. From googling about, I can't find any references of people doing it with open-iscsi, although I see a few references to people asking about it. Anyone know the status on that? http://scst.sourceforge.net/mc_s.html. In short, there's no point in it worth implementation and maintenance effort. Vlad -- 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: mc/s - not yet in open-iscsi?
On Thu, 2010-06-10 at 13:36 +0400, Vladislav Bolkhovitin wrote: Christopher Barry, on 06/10/2010 03:09 AM wrote: Greetings everyone, Had a question about implementing mc/s using open-iscsi today. Wasn't really sure exactly what it was. From googling about, I can't find any references of people doing it with open-iscsi, although I see a few references to people asking about it. Anyone know the status on that? http://scst.sourceforge.net/mc_s.html. In short, there's no point in it worth implementation and maintenance effort. Vlad Thank you Vlad - that completely answered my question. -C -- 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: mc/s - not yet in open-iscsi?
On Thu, 2010-06-10 at 13:35 -0700, Nicholas A. Bellinger wrote: On Thu, 2010-06-10 at 13:36 +0400, Vladislav Bolkhovitin wrote: Christopher Barry, on 06/10/2010 03:09 AM wrote: Greetings everyone, Had a question about implementing mc/s using open-iscsi today. Wasn't really sure exactly what it was. From googling about, I can't find any references of people doing it with open-iscsi, although I see a few references to people asking about it. Anyone know the status on that? http://scst.sourceforge.net/mc_s.html. In short, there's no point in it worth implementation and maintenance effort. Heh, this URL is a bunch of b*llshit handwaving because the iscsi-scst target does not support the complete set of features defined by RFC-3720, namely MC/S and ErrorRecoveryLevel=2, let alone asymmeteric logical unit access (ALUA) MPIO. Vlad, if you are so sure that MC/S is so awful, why don't you put your money where your mouth is and start asking these questions on the IETF IPS list and see what Julian Satran (the RFC editor) has to say about them..? H...? Btw, just for those following along, here is what MC/S and ERL=2 when used in combination (yes, they are complementary) really do: http://linux-iscsi.org/builds/user/nab/Inter.vs.OuterNexus.Multiplexing.pdf Also, I should mention in all fairness that my team was the first to implement both a Target and Initiator capable of MC/S and ErrorRecoveryLevel=2 running on Linux, and the first target capable of running MC/S from multiple initiator implementations. Unfortuately Vlad has never implemented any of these features in either a target or initiator, so really he is not in a position to say what is 'good' or what is 'bad' about MC/S. Best, --nab -- 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: queue_depth vs. initial_cmdsn vs. cmds_max
On 06/09/2010 09:19 AM, Patrick J. LoPresti wrote: Hi, Mike, and thank you for your reply. On Tue, Jun 8, 2010 at 10:00 PM, Mike Christiemicha...@cs.wisc.edu wrote: # To control how many commands the session will queue set # node.session.cmds_max to an integer between 2 and 2048 that is also # a power of 2. The default is 128. node.session.cmds_max = 128 # To control the device's queue depth set node.session.queue_depth # to a value between 1 and 1024. The default is 32. node.session.queue_depth = 32 Let me see if I understand... In this context, device means Linux block device. The kernel's filesystem layer sends SCSI commands to the block device, and queue_depth is the maximum number of outstanding (i.e. not-yet-completed) commands the kernel will allow. In this case, the block device is implemented by the iSCSI driver, which forwards the SCSI commands over the session, which is basically the client-to-server iSCSI socket. cmds_max is the maximum number of outstanding (i.e., not-yet-completed) commands that the iSCSI driver will permit for the session. Yeah, the session is the connection from the initiator/iscsi-driver to the target portal. For this we have a socket. The session can access multiple devices/luns through this session. When you run iscsiadm -m sesssion -P 3 you will see the session and then underneath it the devices/luns accessed through it. Is this correct so far? If so, I have a couple more questions. First, why would I want cmds_max larger than queue_depth? Is it something to do with the protocol (e.g., a single command to the device can become multiple commands in the session)? Or is it just because one session can have multiple targets, which means multiple block devices? Yeah on the updated second one. A session can access multiple logical units. It depends on the target. Some targets will match a target to a lun, others will present X targets with Y LUs accessed through each target. Second, how does the number of commands relate to the amount of data being transferred? Put another way, how much data can a single command request from the disk? It depends. At the block layer there is a /sys/block/sdX/queue/max_sectors_kb which limits the size of the command that can be made. However, there a lot of other things that can prevent us from making IOs that large. At the iscsi level then we break up the scsi command into multiple iscsi packets. These are 48 bytes when not using digests and then the data part of the packet is limited by the MaxRecvDataSegmentLength the target and initiator have negotiated for on their sides. And actually for the initial packet of a write command the FirstBurstLength and ImmediateData come into play. -- 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: mc/s - not yet in open-iscsi?
On Thu, 2010-06-10 at 13:36 +0400, Vladislav Bolkhovitin wrote: Christopher Barry, on 06/10/2010 03:09 AM wrote: Greetings everyone, Had a question about implementing mc/s using open-iscsi today. Wasn't really sure exactly what it was. From googling about, I can't find any references of people doing it with open-iscsi, although I see a few references to people asking about it. Anyone know the status on that? http://scst.sourceforge.net/mc_s.html. In short, there's no point in it worth implementation and maintenance effort. Heh, this URL is a bunch of b*llshit handwaving because the iscsi-scst target does not support the complete set of features defined by RFC-3720, namely MC/S and ErrorRecoveryLevel=2, let alone asymmeteric logical unit access (ALUA) MPIO. Vlad, if you are so sure that MC/S is so awful, why don't you put your money where your mouth is and start asking these questions on the IETF IPS list and see what Julian Satran (the RFC editor) has to say about them..? H...? --nab -- 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: Centos 5.4 bnx2i iscsi woes
Hi Tarun, I think the bug which most likely matched what you were seeing was https://bugzilla.redhat.com/show_bug.cgi?id=572596 This is where the iscsid and uIP daemon were not synchronized when the uIP stack was coming up and iscsid didn't wait for uIP to fullly initialized. From that bugzilla we have generated patches for iscsid and uIP which resulted in the following bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=595549 Where the patches will go into the next version of iscsi-initator-utils. Please let me know if there are any questions or concerns. Thanks again. -Ben On Thu, 2010-06-10 at 15:30 -0700, Tarun Reddy wrote: Ben, Mike, Is there a RedHat bug covered by this? I've searched and the closest I see is https://bugzilla.redhat.com/show_bug.cgi?id=578005 but that seems to indicate that a service network restart would be a workaround. I'm not seeing that work for me. Thank you, Tarun On Mon, May 24, 2010 at 3:16 PM, Benjamin Li be...@broadcom.com wrote: Hi Mike, I don't have a version of brcm_iscsiuio which I have readily avaliable for 5.5.z which has the fix you are looking for without adding new features. I will need to create a version of brcm_iscsiuio with the iscsid/brcm_iscsiuio backported for 5.5.z. When does this need to be accomplished? Thanks again. -Ben On Mon, 2010-05-24 at 14:05 -0700, Mike Christie wrote: On 05/21/2010 07:35 PM, Tarun Reddy wrote: Mike, So is there any update to this? It seems to fix the problem in RHEL 6 testing. http://people.redhat.com/mchristi/iscsi/rhel6.0/iscsi-initiator-utils/ (I think the rhel6 init scripts will not work with RHEL5 perfectly). Ben, did you have a brcm release you wanted me to use for a 5.5.z release (the 5.5.z should not have new features as you know so I could not use the brcm release I used in the RHEL 6 realease). -- 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.
