Re: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
HIMANSHU wrote: Let me take this a chunk at a time :) HIMANSHU wrote: My previous problem that initiator cannot recover the connection after target daemon restart/target machine reboot was solved. It was a really a silly mistake. Initiator side Header,Data digest configuration was not set according to target side. I set both to None.Then it can recover the connection.Though target side settings can be anything out of the 4 options.But it is not still working correctly with CRC32C instead of None. What is actually the need of Header and Data Digest??? Are you changing the digest values between target restarts/reboots? No,I m not changing them.Is that expected during restart/reboot? I was just asking if you were changing them in case it was to some values where the login should fail like if you initially setup both boxes to always want CRC32CS, but then switch to where we always wanted CRC32C on the initiator but never on the target. Have u checked my mail? I did and tried the ones that did not work, but they worked for me with the git head iscsi code and with the svn head iet code. On Jul 3, 7:20 am, Mike Christie [EMAIL PROTECTED] wrote: Does it have something to do with Discovery/Node level authentication?? Or it just checks Header/Data integrity using checksum on both sides to ensure packets are not tampered. Digests are used to ensure packets are the same as what was sent. I am using version 865.Version 868 doesn't make use of Data Digest at all. What do you mean by 868 not making use of data digests? In version 868,in iscsid.conf,DataDigest parameter is not specified like version 865. you are probably taking some default value. Is that with the open-iscsi.org releases or fedora/RHEL/Centos ones? I disabled data digests in the fedora/RHEL ones because they were causing some problems. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
Let me take this a chunk at a time :) HIMANSHU wrote: My previous problem that initiator cannot recover the connection after target daemon restart/target machine reboot was solved. It was a really a silly mistake. Initiator side Header,Data digest configuration was not set according to target side. I set both to None.Then it can recover the connection.Though target side settings can be anything out of the 4 options.But it is not still working correctly with CRC32C instead of None. What is actually the need of Header and Data Digest??? Are you changing the digest values between target restarts/reboots? No,I m not changing them.Is that expected during restart/reboot? Have u checked my mail? On Jul 3, 7:20 am, Mike Christie [EMAIL PROTECTED] wrote: Does it have something to do with Discovery/Node level authentication?? Or it just checks Header/Data integrity using checksum on both sides to ensure packets are not tampered. Digests are used to ensure packets are the same as what was sent. I am using version 865.Version 868 doesn't make use of Data Digest at all. What do you mean by 868 not making use of data digests? In version 868,in iscsid.conf,DataDigest parameter is not specified like version 865. you are probably taking some default value. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
Hello, First of all,Thanks Mike for your continuous help. You are really making this list active. --- Consider the scenario, Open-iSCSI initiator connected to one IET target from target machine. Presently 2 LUN's were attached to it. Target machine adds 3rd LUN to the same target which is exposed to increase storage. Target machine daemon(iscsi-target) is restarted to make the changes reflect the initiator side. Initiator may/may not be undergoing I/O on the 2 exposed LUN's at that instance. on firing iscsiadm -m session -P 3,it will show status as Blocked for 1-2 seconds indicating that target configuration is changed. Then initiator has to perform iscsiadm -m session --rescan to add the 3rd LUN to target already exposed. My question is, 1. Which signal initiator receives from target so that it can know target daemon is restarted?? I want initiator to have access of 3rd LUN after target added it.i.e. on which event,I should run iscsiadm -m session --rescan?? 2. One way could be on initiator side,I should write a daemon/program to run iscsiadm -m session -P 3 continuously to sense if Disk state is blocked and iSCSI state is REOPEN.At that instance, I can run iscsiadm -m session --rescan to make changes reflect. But it will unnecessarily overload CPU a bit. My previous problem that initiator cannot recover the connection after target daemon restart/target machine reboot was solved. It was a really a silly mistake. Initiator side Header,Data digest configuration was not set according to target side. I set both to None.Then it can recover the connection.Though target side settings can be anything out of the 4 options.But it is not still working correctly with CRC32C instead of None. What is actually the need of Header and Data Digest??? Does it have something to do with Discovery/Node level authentication?? Or it just checks Header/Data integrity using checksum on both sides to ensure packets are not tampered. I am using version 865.Version 868 doesn't make use of Data Digest at all. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
Detailed results are mailed to you mike.It is an excel table.I couldn't paste it here. Vaguely,We could conclude that if CRC32C was there @ iscsid.conf,it was unable to recover the connection.Disks show blocked for many time after which they become running but iSCSI connection state remains REOPEN making disks inaccessible. Is that if authentication given on target side(uni/bi) then use CRC32C in iscsid.conf If no authentication,then use None in iscsid.conf CRC32C,None and None,CRC32C options behaviour looks similar. Which one we should go for out of these 4 and when are these used? - --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
On Wed, Jul 02, 2008 at 02:55:15AM -0700, HIMANSHU wrote: Hello, First of all,Thanks Mike for your continuous help. You are really making this list active. --- Consider the scenario, Open-iSCSI initiator connected to one IET target from target machine. Presently 2 LUN's were attached to it. Target machine adds 3rd LUN to the same target which is exposed to increase storage. Target machine daemon(iscsi-target) is restarted to make the changes reflect the initiator side. Initiator may/may not be undergoing I/O on the 2 exposed LUN's at that instance. on firing iscsiadm -m session -P 3,it will show status as Blocked for 1-2 seconds indicating that target configuration is changed. Then initiator has to perform iscsiadm -m session --rescan to add the 3rd LUN to target already exposed. My question is, 1. Which signal initiator receives from target so that it can know target daemon is restarted?? Aren't the latest set of iscsi-target allowing you add a LUN without having to restart the target daemon? I want initiator to have access of 3rd LUN after target added it.i.e. on which event,I should run iscsiadm -m session --rescan?? I don't think the iscsi-target sends SCSI Asynchronous Events, so you probabally want to do something like this: sg_luns /dev/sdone of the block devices.. doesn't matter which one) /tmp/old while (true) do sleep 60 sg_luns /dev/sd. /tmp/new diff /tmp/old /tmp/diff | grep -q if [ $? == 0 ]; then iscsiadm -m node -R fi done 2. One way could be on initiator side,I should write a daemon/program to run iscsiadm -m session -P 3 continuously to sense if Disk state is blocked and iSCSI state is REOPEN.At that instance, I can run iscsiadm -m session --rescan to make changes reflect. But it will unnecessarily overload CPU a bit. My previous problem that initiator cannot recover the connection after target daemon restart/target machine reboot was solved. It was a really a silly mistake. Initiator side Header,Data digest configuration was not set according to target side. I set both to None.Then it can recover the connection.Though target side settings can be anything out of the 4 options.But it is not still working correctly with CRC32C instead of None. What is actually the need of Header and Data Digest??? Does it have something to do with Discovery/Node level authentication?? It is set up during that phase. I would think it would go back to that phase after you killed the iscsi-target thought.. Or it just checks Header/Data integrity using checksum on both sides to ensure packets are not tampered. Correct. Thought its primary purpose isn't to check if somebody altered the packet. There are many ways to do that.. I am using version 865.Version 868 doesn't make use of Data Digest at all. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
Let me take this a chunk at a time :) HIMANSHU wrote: My previous problem that initiator cannot recover the connection after target daemon restart/target machine reboot was solved. It was a really a silly mistake. Initiator side Header,Data digest configuration was not set according to target side. I set both to None.Then it can recover the connection.Though target side settings can be anything out of the 4 options.But it is not still working correctly with CRC32C instead of None. What is actually the need of Header and Data Digest??? Are you changing the digest values between target restarts/reboots? Does it have something to do with Discovery/Node level authentication?? Or it just checks Header/Data integrity using checksum on both sides to ensure packets are not tampered. Digests are used to ensure packets are the same as what was sent. I am using version 865.Version 868 doesn't make use of Data Digest at all. What do you mean by 868 not making use of data digests? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
