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 -~--~~~~--~~--~--~---
Re: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
> Aren't the latest set of iscsi-target allowing you add a LUN without having > to restart the target daemon? They are allowing using "ietadm --op new --tid= --lun= -- params Path=". This is dynamic connection. In static connection,it is not allowing without restarting target daemon. So we can have a combination of static and dynamic wherein we can maintain "ietd.conf" and execute commands whose entry will go in it. > > 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/sd > /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 Yeah..Thnx Konrad.This is really a good solution. We have to install "sg3 utility" for that.But it is OK as it is giving functionality. It will be more worth if we can use still more commands from "sg3" making full use of it.:) > > 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.. Um.can u plz elaborate on Header-Data Digest parameters significance.I will mail u my observations as I cannot paste it here being excel document. > > 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.. If I kept it as "None" on initiator side.What will be the impact? CRC won't be checked.that's it.right? > > 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 -~--~~~~--~~--~--~---
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/sd /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
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 -~--~~~~--~~--~--~---
