Re: corruption in session list
On 04/28/2009 09:28 AM, Erez Zilber wrote: On Mon, Apr 27, 2009 at 6:56 PM, Mike Christie micha...@cs.wisc.edu wrote: Erez Zilber wrote: From time to time, I see errors like the following when I run 'iscsiadm -m session': tcp: [2] []:-1,1 ��A�¹V��� Is it a known bug? I don't know how to reproduce it. It just happens. I have not seen it. Have you seen it in multiple versions of open-iscsi? I'm 2 or 3 commits away from the HEAD. I haven't seen that with other versions. Do you actually have a session with sid 2 running or is it all garbage? Will check that when it happens again. Erez Make sure you do a make clean. I had a good couple of hours with such fun ;-) Boaz --~--~-~--~~~---~--~~ 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: iscsid : mgmt_ipc_write_rsp: rsp to fd 5
Hi, [~] #iscsiadm -m discovery -d 8 -t sendtargets -p 192.168.1.79:3260 -d 8 iscsiadm: ip 192.168.1.79, port 3260, tgpt -1 iscsiadm: Max file limits 1024 1024 iscsid: poll result 1 iscsid: mgmt_ipc_write_rsp: rsp to fd 5 [~] # No change Philippe. On 27 avr, 17:53, Mike Christie micha...@cs.wisc.edu wrote: [~] # iscsiadm -m discovery -d 8 -t sendtargets -p 192.168.1.79:3260 iscsiadm: ip 192.168.1.79, port 3260, tgpt -1 iscsiadm: Max file limits 1024 1024 iscsid: poll result 1 iscsid: mgmt_ipc_write_rsp: rsp to fd 5 Could you do iscsiadm -m discovery -d 8 -t sendtargets -p 192.168.1.79:3260 -d 8 and send all that output? --~--~-~--~~~---~--~~ 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: Tuning iscsi read performance with multipath Redhat 5.3 / SLES 10 SP2 / Oracle Linux / Equallogic
On 24 Apr 2009 at 16:06, Konrad Rzeszutek wrote: On Fri, Apr 24, 2009 at 02:14:43PM -0400, Donald Williams wrote: Have you tried increasing the disk readahead value? #blockdev --setra X /dev/multipath device The default is 256.Use --getra to see current setting. Setting it too high will probably hurt your database performance. Since databases tend to be random, not sequential. I would think that the databases would open the disks with O_DIRECT bypassing the block cache (And hence the disk readahead value isn't used at all). Hi, first a silly question: Shouldn't the read-ahead on the server be as least as hight as the setting on the client to provide any benefit? And two interesting numbers: On one of our busy databases the the read:write ratio is about 10:1 and the tables are severely fragmented On our Linux servers using iSCSI the read:write ratio is about 1:10 because the machines have several GIGs of RAM and the disk caching is very efficient. So the machine just has to send out the writes... 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: login failure-iscsi: received itt 4000000
On 27 Apr 2009 at 10:46, Mike Christie wrote: [...] Apr 24 12:40:33 localhost iscsid: conn 0 login rejected: initiator error - target not found (02/03) It might be related to this. It just means that we tried to log into a target, but it did not exist on the other box. [...] Hi! Is there any documentation (other than the sources) where those numeric codes like (02/03) are explained? 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: gcc warning at iscsi_add_session
On 27 Apr 2009 at 19:20, Boaz Harrosh wrote: drivers/scsi/scsi_transport_iscsi.c: In function 'iscsi_add_session': drivers/scsi/scsi_transport_iscsi.c:678: warning: 'err' may be used uninitialized in this function Hi mike, what ever happened to the fix of above warning? I'm sure I saw a fix in the mailing list but it never made it into mainline (2.6.30-rc3) Hi! I know at least one case where gcc emitted such a warning where the value being used was well-defined in all cases. I don't know if that's true here. In any case it's worth having a look, I guess. 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: Persistent connections across initiator reboot
One more question analogues to this. Suppose I login to 1st target from machine 30.12,it was having node authentication.so I saved its credentials in iscsid.conf and then I fired the discovery command followed by login command.It was successful and those credentials also got stored in nodes and send_targets. Then if I want to login to 2nd target which is also having node authentication from same machine,I am overwriting same iscsid.conf file.So I am loosing my previous credentials from iscsid.conf.Also after discovery,I am loosing previous target information from nodes and send_targets. So solution would be maintaining separate iscsid.conf files per logged in target.Can I do that here? ietd allows to read from different configuration file.right? On Apr 28, 9:19 am, HIMANSHU makhu...@yahoo.co.in wrote: Thank you very much Mike for all this. Can you please give me the test src rpm for CentOS 5.4? On Apr 27, 8:50 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: I am now having 'iscsi-initiator-utils-6.2.0.868-0.18.el5' and performed the steps mentioned in my last post. Still after when I discover using 'iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete',nodes and sendtargets entries gets overwritten. Sorry, sorry, my fault. I was looking up the current devel version. In RHEL 5.3/CentO35.3 and below there is no fix. You have to use the upstream code. I can also give you a test src rpm I am working on for RHEL 5.4/CentOs 5.4 if you want? It has the change needed. --~--~-~--~~~---~--~~ 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: strange behavior on kernel update
On Tue, Apr 28, 2009 at 04:00:08AM +0200, Maddin wrote:
Hi,
i'm using centos with dm-multipath and iscsi as a database system. All
packages are normal centos packages from their mirrors.
This night I was updating centos to the current release (5.3, previous
version was 5.2). So the first thing I have done was stopping the multipathd
and iscsi. After this I was doing the normal update stuff (yum
check-updates, yum clean all, yum update glibc\*, yum update). During the
last yum update the new kernel was installed (2.6.18-128.1.6.el5, previous
was 2.6.18-92.1.22.el5).
During the installation process of the kernel, the yum process hangs.
Looking with ps for the hanging processes, I see that the kernel package was
building the initrd. After killing this process and repeating the yum update
process (this time only the kernel-package) about 5 times, the same strange
failure occurs (process hangs on building initrd). The sixth time I was
stracing the whole update process and see that the mkinitrd process does a
wait-syscall for sth.. After killing this process again I went down to the
server room to reboot the system and try another update process. I reboot
the systems, stops multipathd and iscsi and starting the update process. On
this update I could see that during the mkinitrd process, a kernel message
device-mapper: failed path x:x:x:x occurs. Hmm this is strange I thought,
because I've stopped multipathd and iscsi, so why means the kernel that a
path is failed? Once again killing the mkinitrd process and then starting
The device mapper (a kernel component) still has your multipath entries even
thought you have
killed multipathd and iscsi. It doesn't delete them, unless you
specifically instructs the daemon (multipathd) to do so.
From the standpoint of the kernel, the underlaying block devices got
yanked out and the brain (multipathd) terminated. And any I/O that
touches that multipath device (such as 'pvscan', 'lvscan' which mkinitrd
uses to figure out the boot device) would cause the kernel to notice
that the I/O's aren't going anywhere and mark them as failed.
multipathd and iscsi I've tried another update process. And, yeha, it
works???
.. and depending on your multipath.conf file, the I/O can be queued forever
(queue_if_no_path), or up to a certain time-limit ('no_path_retry'). Or
error out immediately (if you don't have any of those options set). From
your experiment it seems that those flags are set and the mkinitrd
process is in the D state, waiting for the kernel to return a value
after a read/write system call.
If you had deleted the device mapper entries before terminating
multipathd and iscsi this shouldn't have happend. Or if you had set the
multipath configuration to error out immediately you wouldn't hit this.
I could reproduce this behavior on 2 machines, both centos with standard
packages.
Correclty so.
So can anybody comprehend this failure or any ideas?
Cheers
Maddin
--~--~-~--~~~---~--~~
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: iscsid : mgmt_ipc_write_rsp: rsp to fd 5
Philippe wrote: Hi, [~] #iscsiadm -m discovery -d 8 -t sendtargets -p 192.168.1.79:3260 -d 8 iscsiadm: ip 192.168.1.79, port 3260, tgpt -1 iscsiadm: Max file limits 1024 1024 iscsid: poll result 1 iscsid: mgmt_ipc_write_rsp: rsp to fd 5 [~] # No change What version of open-iscsi was this? Could you run it in strace: strace iscsiadm -m discovery -t sendtargets -p 192.168.1.79:3260 --~--~-~--~~~---~--~~ 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: iscsiadm version 2.0-868 incompatibility with older version
Ulrich Windl wrote:
On 27 Apr 2009 at 10:37, Mike Christie wrote:
Ulrich Windl wrote:
Hi,
SLES10 SP2 ships iscsiadm version 2.0-868, while SP1 had an older
version. For
SP1 I used the following command to set all discovered nodes to auto-login:
for sid in $(iscsiadm -m node | awk '{gsub(/^\[/, ); gsub(/\]/, );
print $1 }'
| sort)
Is this just going to get the sid for all the records? If so then I
think you can do
iscsiadm -m node -o update
This will update the setting for all records.
Hi Mike,
yes, the problem with the older release was that the other syntax never
worked,
so I developed that workaround. Basically what one wants is to try a setting
on
one node or portal first, then if it's what one wanted, apply the seting to
the
(desired) rest of the nodes or portals.
do
iscsiadm -m node -r $sid -o update -n node.startup -v automatic
done
What would be the equivalent for the newer version that says: iscsiadm:
node
mode: option '-r' is not allowed/supported?
To change just one record you can do:
iscsiadm -m node -T target -p ip -o update
The manpage says:
-T, --targetname=targetname
Use target targetname.
This should be used along with --portal in node mode, to specify
what the open-iscsi docs refer to as a node or node record.
Note: open-iscsi's use of the word node, does not match the
iSCSI RFC's iSCSI Node term.
How would such a target look like; would iqn.1986-
03.com.hp:fcgw.mpx100:rkdvmis1.0.50001fe1500c1f20.50001fe1500c1f2c be a
valid
sample?
Yeah.
If yo run:
iscsiadm -m session
tcp [2] 10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311
tcp [3] 10.15.85.19:3260,3 iqn.1992-08.com.netapp:sn.33615311
The targetname is the iqn.1992-08.com.netapp:sn.33615311 string.
If you do:
#iscsiadm -m session -P 1
Target: iqn.1992-08.com.netapp:sn.33615311
Current Portal: 10.15.85.19:3260,3
Persistent Portal: 10.15.85.19:3260,3
Iface Transport: tcp
Iface IPaddress: 10.11.14.37
Iface HWaddress: default
Iface Netdev: default
SID: 7
iSCSI Connection State: LOGGED IN
Internal iscsid Session State: NO CHANGE
Then it is the string after the target:
If you run:
iscsiadm -m node
10.15.85.19:3260,3 iqn.1992-08.com.netapp:sn.33615311
10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311
Then again it is the iqn.1992-08.com.netapp:sn.33615311.
./iscsiadm -m node -P 1
and if you did:
iscsiadm -m node -P 1
Target: iqn.1992-08.com.netapp:sn.33615311
Portal: 10.15.84.19:3260,2
Iface Name: iface2
Portal: 10.15.85.19:3260,3
Iface Name: iface2
It is the string after the Target:
This is in the newer READMEs, but I think the one in 868 did not have
this info yet.
or if you want to manipulate records using the sid of running sessions
you can do
iscsidm -m session -r $sid -o update .
That usage is not described my my manpage:
iscsiadm -m session [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -r
sessionid | sysfsdir [ -R ] [ -u | -s ] ]
(the only one where -r occurs)
Strange 2.0-868 should have this:
iscsiadm -m session [ -hV ] [ -d debug_level ] [ -P printlevel] [ -r
sessionid | sysfsdir [ -R | -u | -s ] [ -o operation ] [ -n name ] [ -v
value ] ]\n\
SLES might have taken a rc release where this was not yet added.
--~--~-~--~~~---~--~~
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: login failure-iscsi: received itt 4000000
Ulrich Windl wrote: On 27 Apr 2009 at 10:46, Mike Christie wrote: [...] Apr 24 12:40:33 localhost iscsid: conn 0 login rejected: initiator error - target not found (02/03) It might be related to this. It just means that we tried to log into a target, but it did not exist on the other box. [...] Hi! Is there any documentation (other than the sources) where those numeric codes like (02/03) are explained? That is a iscsi SPEC error value. http://www.ietf.org/rfc/rfc3720.txt Page 161. If you are going to ask, yes, I am planning on converting those to a the strings in there. I got to finish up work stuff (bnx2i addition) first. --~--~-~--~~~---~--~~ 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: strange behavior on kernel update
Hi Konrad,
Konrad Rzeszutek schrieb:
On Tue, Apr 28, 2009 at 04:00:08AM +0200, Maddin wrote:
Hi,
i'm using centos with dm-multipath and iscsi as a database system. All
packages are normal centos packages from their mirrors.
This night I was updating centos to the current release (5.3, previous
version was 5.2). So the first thing I have done was stopping the multipathd
and iscsi. After this I was doing the normal update stuff (yum
check-updates, yum clean all, yum update glibc\*, yum update). During the
last yum update the new kernel was installed (2.6.18-128.1.6.el5, previous
was 2.6.18-92.1.22.el5).
During the installation process of the kernel, the yum process hangs.
Looking with ps for the hanging processes, I see that the kernel package was
building the initrd. After killing this process and repeating the yum update
process (this time only the kernel-package) about 5 times, the same strange
failure occurs (process hangs on building initrd). The sixth time I was
stracing the whole update process and see that the mkinitrd process does a
wait-syscall for sth.. After killing this process again I went down to the
server room to reboot the system and try another update process. I reboot
the systems, stops multipathd and iscsi and starting the update process. On
this update I could see that during the mkinitrd process, a kernel message
device-mapper: failed path x:x:x:x occurs. Hmm this is strange I thought,
because I've stopped multipathd and iscsi, so why means the kernel that a
path is failed? Once again killing the mkinitrd process and then starting
The device mapper (a kernel component) still has your multipath entries even
thought you have
killed multipathd and iscsi. It doesn't delete them, unless you
specifically instructs the daemon (multipathd) to do so.
From the standpoint of the kernel, the underlaying block devices got
yanked out and the brain (multipathd) terminated. And any I/O that
touches that multipath device (such as 'pvscan', 'lvscan' which mkinitrd
uses to figure out the boot device) would cause the kernel to notice
that the I/O's aren't going anywhere and mark them as failed.
Ok that sounds logical to me.
multipathd and iscsi I've tried another update process. And, yeha, it
works???
.. and depending on your multipath.conf file, the I/O can be queued forever
(queue_if_no_path), or up to a certain time-limit ('no_path_retry'). Or
error out immediately (if you don't have any of those options set). From
your experiment it seems that those flags are set and the mkinitrd
process is in the D state, waiting for the kernel to return a value
after a read/write system call.
If you had deleted the device mapper entries before terminating
multipathd and iscsi this shouldn't have happend. Or if you had set the
multipath configuration to error out immediately you wouldn't hit this.
I've set queue_if_no_path to all targets. I'll try to delete all path's
and then updating again.
So thanks in advance for your help.
I could reproduce this behavior on 2 machines, both centos with standard
packages.
Correclty so.
So can anybody comprehend this failure or any ideas?
Cheers
Maddin
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
