> 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=<tid> --lun=<lun> --
params Path=<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<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

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..

Ummmmm.....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
-~----------~----~----~----~------~----~------~--~---

Reply via email to