HIMANSHU wrote:
Yeah mike,This time you hit the Bulls eye.
So only way(from initiators side) to successfully relogin to blocked
target was increasing timeout value which i tried.
Now we have to change the IET code to allow relogin.right?
IET people are not really responding to my
HIMANSHU wrote:
Yeah..I am using IET.
I was getting session recovery timed out after 120 secs when it was
120.
Now as it is 86400,I never observed after 86400sec. that
session recovery timed out after 86400 secs.
Otherwise is it NORMAL behavior of IET that the connection is lost of
The Rule: Only after logout,target daemon can be restarted.
But it sounds little weird.is it?
It looks like a safety feature.
If some I/O going on the initiators side,i cannot logout that target.
You sure about that? Did you do 'iscsiadm -m node -U all' and the
session wouldn't logout?
Thanks a lot Konrad and Mike for your continuous help.
@Konrad
Sorry, I meant to say If I/O going on,it shouldn't be allowed to
logout that target.
Suppose I added few targets and want initiators should know this
change,i should restart iscsi-target daemon.Without this,iscsiadm -
m
I changed timeout as follows.
1. iscsiadm --mode discovery --type sendtargets --portal 192.168.7.174
2. iscsiadm -m node -T iqn.2008-05.com.abcde:Tar1 -p
192.168.7.174:3260 --login
3. iscsiadm -m node -T iqn.2008-05.com.qualexsystems:Tar1 -p
192.168.7.174:3260 -o update -n
HIMANSHU wrote:
Hi..
It is probably not the problem of replacement_timer.
Did you try what I asked? Did you do the same timing in the tests?
In your log you had this:
session13: iscsi: session recovery timed out after 120 secs
When this is is printed out it means the replacment timer
I) How to increase replacement_timeout on initiator?
echo 82400 /sys/block/sdh/device/timeout
or
After discovery,nodes sendtargets are created.In nodes,there is
default file.
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
HIMANSHU wrote:
I) How to increase replacement_timeout on initiator?
echo 82400 /sys/block/sdh/device/timeout
or
Yeah, the timeout above is not the replacement_timeout so writing to
that sysfs file will not help.
After discovery,nodes sendtargets are created.In nodes,there is
Hello All,
1. I am using latest iscsitarget-0.4.16-1 from sourceforge.
Now,can you tell whether it is expected to retain the connection with
initiator once the target is restarted?
-
2. You wrote.
The reason for having you do
On Fri, May 09, 2008 at 02:36:25AM -0700, MAKHU wrote:
Hello All,
1. I am using latest iscsitarget-0.4.16-1 from sourceforge.
And an older version of Open-iSCSI..would say 868-20. Have you tried
using the one that got released about a week ago?
... snip ...
MAKHU wrote:
Conclusion: What is moral of the story i got is that in our target-
initiator pair,Persistent connection is not possible.After target/
Initiator iscsi-target daemon restart(code given below),connection
is lost causing disks to be unusable.
What you should have taken from the
When target is logged in to an initiator and then either target/
initiator is restarted,connection is lost.
Should the connection be restored?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To
On Thu, May 08, 2008 at 08:52:35AM -0700, MAKHU wrote:
When target is logged in to an initiator and then either target/
initiator is restarted,connection is lost.
It goes the other way. Initiator logs in the target.
If the initiator (client) is restarted the connection would be lost.
If the
Konrad Rzeszutek wrote:
2). If is a EqualLogic, send a AsyncMsg telling the initiator that the
block
device is going to be off-line.
What is this? I do not think we handle this. Is it a verndor specific
async iscsi event?
Yes. To be exact attached is a TCP dump, look for seq no
14 matches
Mail list logo
