Re: open-iscsi isns registration fails using Solaris isns server
ok it worked after a reboot.but dropping eid does not make sense to me. What might be the exact cause of this eid being the FQDN not to be authorised??? On Tue, Jan 13, 2009 at 11:27 PM, Nikhil nikhil.talpalli...@gmail.comwrote: Hi, It does not work for me :( I used target name instead of eid . but the same err HELP! cheers, nikhil On Jan 5, 2:21 am, Albert Pauw albert.p...@gmail.com wrote: For the watchfull observant,the patch is shown in reverse, it should read: --- usr/isns.c 2009-01-04 12:11:27.0 +0100 +++ usr/isns.c.new 2009-01-04 11:17:43.0 +0100 @@ -162,10 +162,10 @@ length += isns_tlv_set(tlv, ISNS_ATTR_ISCSI_NAME, strlen (name), name); length += isns_tlv_set(tlv, ISNS_ATTR_ENTITY_IDENTIFIER, - strlen(eid), eid); + strlen(name), name); length += isns_tlv_set(tlv, 0, 0, 0); length += isns_tlv_set(tlv, ISNS_ATTR_ENTITY_IDENTIFIER, - strlen(eid), eid); + strlen(name), name);; length += isns_tlv_set(tlv, ISNS_ATTR_ENTITY_PROTOCOL, sizeof(type), type); -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) --~--~-~--~~~---~--~~ 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: Data loss on network/service failure
HIMANSHU schrieb: IET target is connected by MS initiator.Data transfer is going on on the connected disk on initiator. I don't see how your question fits here - you use IET as a target, and a MS initiator. This is open-iscsi (initiator) list, not a general iSCSI-related-questions list. TCP connection failed(because of any reason,service failure,problems in kernel modules) at say 't1' second.Initiator kept trying for reconnect. Initiator actually recognizes that target is down at say 't2' seconds. Then for the time between 't1' and 't2',data is written on the cache on initiator side giving illusion of data transfer.After some time,it gave delayed write error. So data is not actually stored on the target. What can we do here?Using high capacity network can be the solution in case of dedicated framework so that initiator will recognize the failure as early as possible. open-iscsi has configurable timeouts. For example, by setting node.session.timeo.replacement_timeout to a higher value than the default 120 seconds allows your initiator to survive network failures lasting minutes, hours, days etc., depending on how big the timeout you set. Any task which needs to access data on the target, but can't, because of a network failure, will be put into an uninterruptible sleep until the target is accessible again (or the timeout triggers, which means I/O error). -- Tomasz Chmielewski http://wpkg.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Data loss on network/service failure
IET target is connected by MS initiator.Data transfer is going on on the connected disk on initiator. TCP connection failed(because of any reason,service failure,problems in kernel modules) at say 't1' second.Initiator kept trying for reconnect. Initiator actually recognizes that target is down at say 't2' seconds. Then for the time between 't1' and 't2',data is written on the cache on initiator side giving illusion of data transfer.After some time,it gave delayed write error. So data is not actually stored on the target. What can we do here?Using high capacity network can be the solution in case of dedicated framework so that initiator will recognize the failure as early as possible. --~--~-~--~~~---~--~~ 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: Data loss on network/service failure
On 14 Jan 2009 at 4:25, HIMANSHU wrote: IET target is connected by MS initiator.Data transfer is going on on the connected disk on initiator. TCP connection failed(because of any reason,service failure,problems in kernel modules) at say 't1' second.Initiator kept trying for reconnect. Initiator actually recognizes that target is down at say 't2' seconds. Then for the time between 't1' and 't2',data is written on the cache on initiator side giving illusion of data transfer.After some time,it gave delayed write error. It's not an illusion of data transfer, but a shift in responsibility: Having buffered the data to write, the kernel is responsible to finally write the data. In HP-UX (without iSCSI) messages may look like these: vmunix: LVM: WARNING: VG 64 0x1f: LV 1: Some I/O requests to this LV are waiting indefinitely for an unavailable PV. These requests will be queued until the PV becomes available (or a timeout is specified for the LV). [...] vmunix: LVM: NOTICE: VG 64 0x1f: LV 1: All I/O requests to this LV that were waiting indefinitely for an unavailable PV have now completed. Naturally if the user panics in between, data is lost. The sysadmin has the responsibility to restore the network connection in the iSCSI case. If you application relies that the data is written upon return of a write(), it should use the O_SYNC (in Linux) open() flag. So data is not actually stored on the target. What can we do here?Using high capacity network can be the solution in case of dedicated framework so that initiator will recognize the failure as early as possible. I'd consider this type of failure the same as if you unplug the IDE or SCSI cable while the system is running. If your system is very stable, it can recover from the situation if the cable is reconnected. However it's usually best to avoid such situations. Just my opinion 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: [PATCH] iscsi_tcp - make padbuf non-static
On Thu, 2009-01-08 at 15:06 -0600, Mike Christie wrote: Karen Xie wrote: [PATCH] iscsi_tcp - make padbuf non-static From: Karen Xie k...@chelsio.com virt_to_page() call should not be used on kernel text and data addresses. virt_to_page() is used by sg_init_one(). So change padbuf to be allocated within iscsi_segment. Signed-off-by: Karen Xie k...@chelsio.com Thanks for finding this. Acked-by: Mike Christie micha...@cs.wisc.edu Could one of you regenerate this against current git head, please, it seems to have suffered from the iscsi to libiscsi move. James --~--~-~--~~~---~--~~ 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: [PATCH] iscsi: Kconfig option for debug prints.
Boaz Harrosh wrote: Remove the dark ages /* define debug_print */ in code, to use a Kconfig option. With a system like Kconfig, in code, commented out, configuration options are slavery and hard work. (version control, manual edit ... need I say more) I've used an int config bit-mask so more areas of code can be selected with one Koption, but mainly so that allmodconfig will not turn it on. bit-1 - will turn on prints for libiscsi. bit-2 - will turn on prints for libiscsi_tcp iscsi_tcp. More iscsi drivers should use more bits. Signed-off-by: Boaz Harrosh bharr...@panasas.com --- drivers/scsi/Kconfig| 15 +++ drivers/scsi/iscsi_tcp.c|7 --- drivers/scsi/iscsi_tcp.h|6 ++ drivers/scsi/libiscsi_tcp.c |7 --- include/scsi/libiscsi.h |3 +-- 5 files changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index d25d21e..6ef42f6 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -352,6 +352,21 @@ config ISCSI_TCP http://open-iscsi.org +config ISCSI_DEBUG + int ISCSI debug prints + depends on SCSI_ISCSI_ATTRS + default 0 + help + This is a bit-mask that turns some debug printing to Kernel's + Messages file. Each bit turns on another area of the code: + 1 - Turn on prints from iscsi libraries. + 2 - Turns on prints from iscsi_tcp operations. Is this bit 1, bit 2, or value 1, value 2? Not clear to me. If it's bit numbers, what about bit 0? + Note to programmers: Use more bits in this bit-mask for other iscsi + drivers. + If you found a problem with ISCSI, please turn this on to + help us debug the problem. Send the Messages file plus problem + description to open-iscsi@googlegroups.com mailing-list + source drivers/scsi/cxgb3i/Kconfig config SGIWD93_SCSI diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c index a566aa9..af092a8 100644 --- a/drivers/scsi/iscsi_tcp.c +++ b/drivers/scsi/iscsi_tcp.c @@ -48,13 +48,6 @@ MODULE_AUTHOR(Mike Christie micha...@cs.wisc.edu, Alex Aizman itn...@yahoo.com); MODULE_DESCRIPTION(iSCSI/TCP data-path); MODULE_LICENSE(GPL); -#undef DEBUG_TCP - -#ifdef DEBUG_TCP -#define debug_tcp(fmt...) printk(KERN_INFO tcp: fmt) -#else -#define debug_tcp(fmt...) -#endif static struct scsi_transport_template *iscsi_sw_tcp_scsi_transport; static struct scsi_host_template iscsi_sw_tcp_sht; diff --git a/drivers/scsi/iscsi_tcp.h b/drivers/scsi/iscsi_tcp.h index ca6b7bc..1341b02 100644 --- a/drivers/scsi/iscsi_tcp.h +++ b/drivers/scsi/iscsi_tcp.h @@ -25,6 +25,12 @@ #include scsi/libiscsi.h #include scsi/libiscsi_tcp.h +#if (CONFIG_ISCSI_DEBUG 2) +#define debug_tcp(fmt...) printk(KERN_INFO tcp: fmt) +#else +#define debug_tcp(fmt...) +#endif + struct socket; struct iscsi_tcp_conn; diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c index 12354c5..4c9f827 100644 --- a/drivers/scsi/libiscsi_tcp.c +++ b/drivers/scsi/libiscsi_tcp.c @@ -49,13 +49,6 @@ MODULE_AUTHOR(Mike Christie micha...@cs.wisc.edu, Alex Aizman itn...@yahoo.com); MODULE_DESCRIPTION(iSCSI/TCP data-path); MODULE_LICENSE(GPL); -#undef DEBUG_TCP - -#ifdef DEBUG_TCP -#define debug_tcp(fmt...) printk(KERN_INFO tcp: fmt) -#else -#define debug_tcp(fmt...) -#endif static int iscsi_tcp_hdr_recv_done(struct iscsi_tcp_conn *tcp_conn, struct iscsi_segment *segment); diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h index 7360e19..2421c2a 100644 --- a/include/scsi/libiscsi.h +++ b/include/scsi/libiscsi.h @@ -45,8 +45,7 @@ struct iscsi_session; struct iscsi_nopin; struct device; -/* #define DEBUG_SCSI */ -#ifdef DEBUG_SCSI +#if (CONFIG_ISCSI_DEBUG 1) #define debug_scsi(fmt...) printk(KERN_INFO iscsi: fmt) #else #define debug_scsi(fmt...) -- ~Randy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bad TCP Checksums Over Loopback
Hello all, I tried a simple test: 1. Installed an iSCSI target. I tried this with both IET (iscsitarget.sourceforge.net) and tgt (apt-get install tgt). 2. Created a 2GB file to use as the target. 3. Connected to the target with iscsiadm. 4. Ran the following command to test read throughput: dd if=/dev/sdc of=/dev/null bs=128M count=16 5. Ran the following command to test write throughput: dd if=/dev/zero of=/dev/sdc bs=128M count=16 (where /dev/sdc is the iSCSI device) For read throughput I get about 98MB/s, and for write throughput about 75MB/s. I tried to figure out why writes are so much slower, so I opened up wireshark and looked at the packets. I captured 256,270 packets. Here are some statistics from wireshark: Bad checksum(TCP): 35,963 Bad checksum(UDP): 4 Previous segment lost (TCP): 24,502 ACKed lost segment (TCP): 51,651 I would bet that this has something to do with the low throughput. (For the read test, everything looks fine in wireshark). I uploaded the compressed dump here: http://www.fsl.cs.sunysb.edu/~avishay/iscsi-loopback-write.dump.tgz I'm assuming the problem lies in open-iscsi because I tried two different targets with the same results, and I'm working over loopback (no network issues). Some more info: # uname -a Linux guri 2.6.24-16-server #1 SMP Thu Apr 10 13:15:38 UTC 2008 x86_64 GNU/Linux # cat /etc/issue Ubuntu 8.04.1 \n \l # iscsiadm -V iscsiadm version 2.0-865 # dpkg -l | grep open-iscsi ii open-iscsi 2.0.865-1ubuntu3 High performance, transport independent iSCS # iscsiadm -m discovery -t st -p 127.0.0.1 127.0.0.1:3260,1 iqn.2001-04.com.example:storage.disk2.sys1.xyz # iscsiadm -m node -T iqn.2001-04.com.example:storage.disk2.sys1.xyz - p 127.0.0.1 -l Login session [iface: default, target: iqn. 2001-04.com.example:storage.disk2.sys1.xyz, portal: 127.0.0.1,3260] # fdisk -l /dev/sdc Disk /dev/sdc: 2147 MB, 2147483648 bytes 67 heads, 62 sectors/track, 1009 cylinders Units = cylinders of 4154 * 512 = 2126848 bytes Disk identifier: 0x Disk /dev/sdc doesn't contain a valid partition table Any help would be appreciated! Thanks a lot! Avishay --~--~-~--~~~---~--~~ 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: Bad TCP Checksums Over Loopback
On Mon, Jan 12, 2009 at 11:48 AM, avis...@gmail.com wrote: Here are some statistics from wireshark: Bad checksum(TCP): 35,963 Usually this means that Wireshark was unable to capture all packets, not that there was a problem with the packets themselves. Bart. --~--~-~--~~~---~--~~ 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: open-iscsi isns registration fails using Solaris isns server
Hi, The iSNS server refuses connection to a network entity (eid) if there exists an object already registered with the same network entity id but different iSCSI node type(i.e. one initator and other target or vice versa). But if the iSCSI node type is same (in case of two targets on same network entity) iSNS server accepts the connection. Conclusion: If we use iSNS discovery method, we cannot have initiator and target on the same m/c with the same DNS name. cheers,nikhil On Wed, Jan 14, 2009 at 3:26 PM, Nikhil Talpallikar nikhil.talpalli...@gmail.com wrote: ok it worked after a reboot.but dropping eid does not make sense to me. What might be the exact cause of this eid being the FQDN not to be authorised??? On Tue, Jan 13, 2009 at 11:27 PM, Nikhil nikhil.talpalli...@gmail.comwrote: Hi, It does not work for me :( I used target name instead of eid . but the same err HELP! cheers, nikhil On Jan 5, 2:21 am, Albert Pauw albert.p...@gmail.com wrote: For the watchfull observant,the patch is shown in reverse, it should read: --- usr/isns.c 2009-01-04 12:11:27.0 +0100 +++ usr/isns.c.new 2009-01-04 11:17:43.0 +0100 @@ -162,10 +162,10 @@ length += isns_tlv_set(tlv, ISNS_ATTR_ISCSI_NAME, strlen (name), name); length += isns_tlv_set(tlv, ISNS_ATTR_ENTITY_IDENTIFIER, - strlen(eid), eid); + strlen(name), name); length += isns_tlv_set(tlv, 0, 0, 0); length += isns_tlv_set(tlv, ISNS_ATTR_ENTITY_IDENTIFIER, - strlen(eid), eid); + strlen(name), name);; length += isns_tlv_set(tlv, ISNS_ATTR_ENTITY_PROTOCOL, sizeof(type), type); -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
