On 11/03/2011 08:23 AM, Sebastian Riemer wrote:
> Hi all,
>
> we've found out that open-iscsi (also with newest userspace source from
> Git, 3.0.4 kernel) immediately trys to disconnect the iSER session upon
> connection loss. Why is that so? This is blocked if the device is in use.
If there is a connection loss then we need to reconnect to the target.
If when you mention open-iscsi tries to disconnect the iSER session that
you mean iscsi_iser_ep_disconnect is run, then that should just be
cleaning up the iser level resources of the previous connection so we
can create a new one. During this time the actual devices like scsi
devices /dev/sdX accessed through the session/connection should be
blocked (/sys/block/sdX/device/state should be "blocked") so IO is not
sent to them while we are doing session recovery. That does not affect
the iser recovery normally though (However it would if the devices got
removed somehow like you described in your first mail).
Is iser recovery stuck on that sync cache command like here:
Oct 25 13:36:07 server14 kernel: [79490.310169] sd 6:0:0:215:
[sdhi] Synchronizing SCSI cache
That should not be getting sent as result of just the recovery process.
You never responded with the iscsi login response code the target was
sending. I think you just sent the ib/iser level ones. Could you perform
your test again but run iscsid in debugging mode and send me all the
output? Instead of start iscsid like would normally do
iscsid -d 8 -f &
then run iscsiadm to login to your target
iscsiadm -m node -T target -p ip -l
Run your test. Then send me the iscsid output and send me all of the
/var/log/messages output.
>
> The Solaris COMSTAR iSER target doesn't show any errors.
>
> We have our QEMU/KVM VMs with Debian Squeeze running inside with ext3 on
> the iSER storage. I ran a continuous dd to a file inside the VM to
> produce some IO.
>
> Meanwhile on the host, I ran a little script with a timed loop of
> "ibportstate <LID> <port> reset" to hold down the IB link ("disable"
> only works for IB switches).
>
> After 120s default replacement_timeout the errors are reported to the VM
> and in the moment the IB link comes available again ext3 breaks always
> for sure (becomes read-only).
> TCP over Ethernet would reconnect and resend packets as if there wasn't
> any error. Can such a behaviour be implemented with iSER, too?
Do you mean iscsi_tcp reconnects before the replacement_timeout? If so
iser should be doing this too. It is a bug if it is not coming back
until after replcement_timeout seconds if the problem has been fixed
within that many seconds.
--
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
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
