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 po
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 t
Konrad Rzeszutek wrote:
> 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 t
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, l
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
"Mike Christie" wrote
1. Are the disks really unusable? What happens when you do 'dd if=/dev/
sdh of=/dev/null count=1' ?
# dd if=/dev/sdh of=/dev/null count=1
# Initially for 5-7 minutes,terminal was completely
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
node.sessi
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,th
Hi..
It is probably not the problem of "replacement_timer".
If i use
Target = "iscsitarget-0.4.15-1"
Initiator = "iscsi-initiator-utils-6.2.0.742-0.5.el5"
Then connection is persistent making disks usable.
This target is not having kernel support above 6.18.
--
On Tue, May 13, 2008 at 09:45:24AM -0700, HIMANSHU wrote:
>
>
> Hi..
>
> It is probably not the problem of "replacement_timer".
>
> If i use
>
> Target = "iscsitarget-0.4.15-1"
> Initiator = "iscsi-initiator-utils-6.2.0.742-0.5.el5"
>
> Then connection is persistent making disks usable.
> Th
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 t
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
node.session.timeo.
On Mon, May 19, 2008 at 06:18:44AM -0700, HIMANSHU wrote:
>
> 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.
HIMANSHU wrote:
> 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:326
Finally,if not achieved,Should i prohibit target daemon restart?Will
that be ethical?
The Rule: Only after "logout",target daemon can be restarted.
But it sounds little weird.is it?
If some I/O going on the initiators side,i cannot logout that target.
Without restarting target daemon,we can no
I already tried 2 options specified by you.
Here's the "iscsid.conf"
(..) values are defaults.Already tried with them.
node.startup = manual
node.session.timeo.replacement_timeout = 86400(120)
node.session.iscsi.FastAbort = No(Yes)
node.conn[0].timeo.logout_timeout = 86400(1
> 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 l
HIMANSHU wrote:
> I already tried 2 options specified by you.
>
> Here's the "iscsid.conf"
>
> (..) values are defaults.Already tried with them.
>
> node.startup = manual
>
>
> node.session.timeo.replacement_timeout = 86400(120)
Yes. This looks good. If you have it in iscsi.conf you
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 discove
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 connectio
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
23 matches
Mail list logo
