Re: [linux-iscsi-devel] [question] deferred sense

Tom Coughlan
2005-01-06T16:43:24Z

On Wed, 2005-01-05 at 11:44, James Bottomley wrote:
> On Wed, 2005-01-05 at 16:23 +0100, Christoph Hellwig wrote:
> > On Wed, Jan 05, 2005 at 09:21:12AM -0600, Scott M. Ferris wrote:
> > > To be more specific, there were some devices that would fail a command
> > > and return deferred sense. The command didn't complete at the target,
> > > and the kernel wasn't retrying it because the sense was deferred
> > > rather than current. For those devices, the translation produced the
> > > desired retry.
> >
> > Do you remember these devices? Might be worth adding a midlayer
> > blacklist entry for them.
>
> That's certainly possible ... although we'd need a lot more details.
> Any device that returns deferred sense for a current error is pretty
> badly broken according to the spec.

If a current command returns deferred sense, the SCSI spec. requires
that the current command shall not have been executed [1]. So, if at
some point in the past the kernel did not retry a current command that
returned deferred sense, the iscsi folks would have forced the retry by
converting deferred sense to current sense. The scenario does not
require a device that is working incorrectly.

The big flaw in what iscsi did is the case where the deferred sense
indicates a non-fatal error. In that case, iscsi converts it to current,
the mitlayer examines it and determines that it does not require a
retry. This causes the current command to complete to the application
even though it was not executed by the device.

It looks to me as though the 2.4 iscsi driver is susceptible to this. It
is probably not seen in practice because disk devices that return
non-fatal deferred sense are rare (it probably requires the PER bit set
in the error recovery mode page?). Anyone know for sure?

[1] If the task terminates with CHECK CONDITION status and the sense
data describes a deferred error the command for the terminated task
shall not have been processed. (SPC-3)