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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
