Re: How can I list logged in nodes?
On Jan 8, 6:39 pm, Konrad Rzeszutek kon...@virtualiron.com wrote: On Thu, Jan 08, 2009 at 10:00:31AM -0800, chris1.nore...@googlemail.com wrote: Hi, is there a way using iscsiadm to list only nodes which are currently logged in? I find that running iscsiadm -m node always lists discovered nodes, but can't find a way to list only those which are logged in and therefore available. iscsiadm -m session Will do it. That worked, thanks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Stopping iscsiadm from automatically reconnecting
This may be a Fedora specific question, I'm not sure (Fedora 9 in my case)... I connect to an iSCSI node as follows: # /sbin/iscsiadm -m node --targetname iqn. 1997-10.com.snapserver:snap727166:iscsi0 --portal 192.168.1.100:3260 -- login Then I can see that I am connected: # /sbin/iscsiadm -m session tcp: [1] 192.168.1.100:3260,1 iqn. 1997-10.com.snapserver:snap727166:iscsi0 Now I want to disconnect (logout) # /sbin/iscsiadm -m node --targetname iqn. 1997-10.com.snapserver:snap727166:iscsi0 --portal 192.168.1.100:3260 -- logout Logging out of session [sid: 1, target: iqn. 1997-10.com.snapserver:snap727166:iscsi0, portal: 192.168.1.100,3260] Logout of [sid: 1, target: iqn. 1997-10.com.snapserver:snap727166:iscsi0, portal: 192.168.1.100,3260]: successful Now I reboot my server and want it to stay logged out, but it is automatically logged in. So after the reboot: # /sbin/iscsiadm -m session tcp: [1] 192.168.1.100:3260,1 iqn. 1997-10.com.snapserver:snap727166:iscsi0 Is there any way, preferably using iscsiadm, to disconnect a node such that it isn't automatically reconnected? Or do I have to manually edit a config file somewhere? Thanks, Chris. --~--~-~--~~~---~--~~ 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: connection, host resets, I/O errors eventually (DRBD, but not only)
Mike Christie schrieb:
The scsi layer sets a timeout on each command. If it does not execute in
X seconds, it will run the iscsi eh.
So you can increase the scsi command time:
To modify the udev rule open /etc/udev/rules.d/50-udev.rules, and find the
following lines:
ACTION==add, SUBSYSTEM==scsi , SYSFS{type}==0|7|14, \
RUN+=/bin/sh -c 'echo 60 /sys$$DEVPATH/timeout'
and you probably want to decrease the number of oustanding commands by
setting the node.session.cmds_max for that session. With 50 kB/s you
might as well set this to 1 command.
This helps a bit, but after some time, something weird happens.
I increased the timeout to 240 seconds.
The data flows fine for some time, but after a couple of minutes, every
program running on that initiator machine seems to freeze (i.e. ping
stops to ping, top stops to refresh the data, they can't be
interrupted / won't exit with ctrl+c).
There is no traffic any more between the target and the initiator.
The machine is a bit alive, as it replies to pings and responds to
sysrq magic, and I can switch VTs (ctrl+alt+F1...).
The machine has its root filesystem accessible via iSCSI (via fast LAN,
to a different target) which can somehow contribute to the problem? It
runs a 2.6.22 kernel.
Some bad interaction if the initiator is connected to two targets with
different IPs, and connection to one target is very slow?
No such phenomenon on a machine with rootfs on SATA, where everything
works fine.
--
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
-~--~~~~--~~--~--~---
Re: connection, host resets, I/O errors eventually (DRBD, but not only)
On Thu, Jan 8, 2009 at 12:44 PM, Tomasz Chmielewski man...@wpkg.org wrote:
Anyone using iSCSI over DRBD? And a slow internet link perhaps?
How reliable is the link you are using -- which percentage of packets
is lost ? You can test this e.g. with the ping command. The following
command will generate about 32 KB/s of network traffic and reports the
percentage of lost packets:
# ping -q -i 0.01 -c1000 -s160 ${remote_ip}
PING 192.168.1.102 (192.168.1.102) 160(188) bytes of data.
--- 192.168.1.102 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 8997ms
rtt min/avg/max/mdev = 0.000/0.048/0.474/0.027 ms
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: connection, host resets, I/O errors eventually (DRBD, but not only)
On Fri, Jan 9, 2009 at 3:22 PM, Tomasz Chmielewski man...@wpkg.org wrote:
Bart Van Assche schrieb:
# ping -q -i 0.01 -c1000 -s160 ${remote_ip}
I get about 1% losses.
IMHO running iSCSI over a slow link should work, but a packet loss of
1% is troublesome. On a local network the packet loss rate is about
0.001% (1e-5) for 1000-byte packets.
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: connection, host resets, I/O errors eventually (DRBD, but not only)
Bart Van Assche schrieb:
On Fri, Jan 9, 2009 at 3:22 PM, Tomasz Chmielewski man...@wpkg.org wrote:
Bart Van Assche schrieb:
# ping -q -i 0.01 -c1000 -s160 ${remote_ip}
I get about 1% losses.
IMHO running iSCSI over a slow link should work, but a packet loss of
1% is troublesome. On a local network the packet loss rate is about
0.001% (1e-5) for 1000-byte packets.
It's not really running iSCSI over a slow link in this case.
DRBD synchronizes two block devices, over a slow link in this case:
P - primary node, accessed by the target, accessed by the initiator
S - secondary node / synchronized area
U - unsynchronized area
PPP
slow link
SSS
Slow link is used to transfer data for unsynchronized area.
Now, if the initiator begins to write data, DRBD has to transfer it to
the secondary node before the write is completed: writes flow over a
slow link and compete with background synchronization in the meantime.
As a result, we can say that iSCSI is running over a slow link.
Mike's suggestion help though - increasing timeouts and decreasing the
number of outstanding commands help here.
One more note - I see such connection/host resets from time to time also
when using a gigabit ethernet and a very loaded target (no I/O errors
though, everything recovers on time with the default values).
--
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
-~--~~~~--~~--~--~---
[Open/iSCSI] Memory leak in repetitive --login/--logout with v2.0-870.1
Greetings Mike, Hannes and Co, During some recent testing using the Open/iSCSI Initiator v2.0-870.1, against the LIO-Target v3.0 tree, I noticed that while running the following script: while [ 1 ]; do iscsiadm -m node -T $TARGETNAME -p $PORTAL --login iscsiadm -m node -T $TARGETNAME -p $PORTAL --logout done for an extended period of time that I started getting OOM failures on the VMs running Open/iSCSI. Upon closer examination, this is what I found: Open-iSCSI Node 1 Linux ubuntu 2.6.27.10 #2 SMP Tue Jan 6 18:33:00 PST 2009 i686 GNU/Linux Using open-iscsi-2.0-870.1: [78196.520214] scsi7981 : iSCSI Initiator over TCP/IP [78284.175307] scsi7982 : iSCSI Initiator over TCP/IP [78338.568656] scsi7983 : iSCSI Initiator over TCP/IP [78405.22] scsi7984 : iSCSI Initiator over TCP/IP Output from slaptop: OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 1037001 1036598 99%0.03K 9177 113 36708K size-32 - Open-iSCSI Node 2 Linux opensuse 2.6.22.5-31-default #1 SMP 2007/09/21 22:29:00 UTC i686 i686 i386 GNU/Linux scsi7046 : iSCSI Initiator over TCP/IP scsi7047 : iSCSI Initiator over TCP/IP scsi7048 : iSCSI Initiator over TCP/IP scsi7049 : iSCSI Initiator over TCP/IP Output from slabtop: OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 914057 913581 99%0.03K 8089 113 32356K size-32 - So it appears that memory is getting leaked in the size-32 range with each --login + --logout invocation. I also tried the same test with the shipping Open/iSCSI code in Debian v4 and OpenSuse 10.3 and these also suffer from the same issue. Also of interest is that running the following script for Discovery SendTargets *DOES NOT* reproduce the leak. while [ 1 ]; do iscsiadm -m discovery -t sendtargets -p $PORTAL done Please let me know if there is anything else I can do to help diagnose the issue. Many thanks for your most valuable of time, --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-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 -~--~~~~--~~--~--~---
