Erez Zilber wrote:
> Hi,
> I'm running a setup of open-iscsi & SCST. In order to test error
> scenarios during a WRITE command, I've added a delay in SCST, so after
> it receives the command, it doesn't send an R2T for 20 seconds. I also
> modified the device timeout on the initiator side to 5 seconds.
> However, I don't see an 'abort' for that command. Instead, I see that

How are you looking? With ethereal? Did you see a TUR get sent before 
the session recovery?

Could you try my linux-2.6-iscsi git tree and turn on debugging?

> open-iscsi logs in again after 10 seconds and sends the command again.

Do you see something about a target reset or host reset?

> SCST also cleans up the session.

If the initiator thinks the abort failed (actually it is more like we 
will return failed if we think it is possible that someone could still 
be accessing the commands buffers, because we do not want scsi-ml to 
start using them again) it would return FAILED to the scsi-eh which for 
us would end up running the host/target reset, which we just drop the 
session for.

We discussed before we need to modify how we decided when to return 
failed and we need to send a target reset for the host/target reset 
handler because the target reset and session relogin have different 
clearing effects. Vlad also has concerns about the tcp/ip connection 
teardown and buildup.

> Can anyone explain the reason for this behavior? I would expect that

iser and iscsi_tcp both hooked in the same libiscsi.c eh code. You 
should know this :)

> scsi-ml on the initiator side will send an 'abort' after 5 seconds.
> Thanks,
> Erez
> > 

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to