Thanks Mike,

Its good to hear that SCSI BUSY and SCSI Task_Set_Full are both handled
correctly by the linux kernel.


The bug must be in my code then!

I'll look deeper at the wireshark traces.

thanks

iscsi devel man.

On Thu, Aug 25, 2011 at 4:39 PM, Mike Christie <micha...@cs.wisc.edu> wrote:

> On 08/25/2011 05:23 PM, iscsi developer man wrote:
> > Thanks Mike,
> >
> > So what happens if we return the task set full or the busy status
> forever?
> > Does the host get an io error at a certain timeout, does the host
> silently
> > return back to the application that the operation has completed
> > successfully,  or does it retry indefinitely?
> >
>
> The info below is for the current upstream kernel. It is probably
> correct from about 2.6.18 - 3.*.
>
> There is a max time value that the scsi layer will retry. It depends on
> the command type. The algorithm is:
>
> (scsi_cmnd->allowed + 1) * scsi_cmnd->timeout.
>
> The allowed value for disk IO is 5. The timeout depends on your distro.
> You can see it in /sys/block/sdX/device/timeout. The kernel sets it to
> 30 but some distro udev version set it to 60. Users can set it to
> whatever makes them happy so who knows.
>
> If the command has not completed in ((scsi_cmnd->allowed + 1) *
> scsi_cmnd->timeout) seconds then the command is failed. In
> /var/log/messages you would see:
>
> "timing out command, waited X seconds",
>
> And the upper layers would get some error. The error value depends on
> the IO type. The block layer, dm, file systems (kernel stuff) gets -EIO.
> If you were doing SG IO then you would see the scsi status value you set
> in the SG IO's error data.
>
>
>

-- 
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.

Reply via email to