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<one 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 -~----------~----~----~----~------~----~------~--~---
