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

[Douglas Gilbert <dougg@torque.net>]

Douglas Gilbert wrote:
> Tom Coughlan wrote:
> 
>> 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?
> 
> 
> Tom,
>  From my reading of SBC-2 (rev 16, 13 Nov 2004) deferred errors
> cannot be turned off by a mode page. The VERIFY and
> WRITE AND VERIFY commands can be used to make sure blocks get
> to the media (or not) without deferred errors. There are also
> the "Force Unit Access" (FUA and FUA_NV) bits in the READ and
> WRITE commands (but not the 6 byte variants).
> 
> The t10 folks have added the idea of non-volatile cache in
> a disk (more likely a RAID) which further complicates things.
> Now a deferred error could theoretically span a power cycle!
> 
> The PER bit in the Read-Write Error Recovery mode page (SBC-2
> rev 16 section 6.3.4) controls whether RECOVERED ERRORs are
> reported or not. Also if the ARRE bit (for reads) and/or the
> AWRE bit (for writes) are set in the same mode
> page, the offending block will be remapped (whether a recovered
> error is reported on not). If PER is 0 then RECOVERED ERRORs
> are not reported. [In any case the Error Counter log pages
> should reflect the problems (and perhaps the "grown" defect
> list) so smartmontools may be of use.]
> 
>> [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) 
> 
> 
> I fear my tinkering with sense descriptor data in
> the mid level may have tripped up on this case (if
> it wasn't already broken), that is: a deferred error
> report must cause the current command to be retried,
> even if the deferred error was reporting a
> recovered error. This case can only arise when PER=1.

Reviewing the error paths in lk 2.6 for deferred errors
indicates that the effected (innocent) command will be
retried in scsi_softirq() unless:
   - the retry count is exceeded (always true for sg usage)
   - or blk_noretry_request() returns true

Does fast path code want to (or know how to) process
deferred errors?
Even when deferred errors are retried this is done
silently unless an appropriate logging_level happens
to be set at the time (unlikely).

Doug Gilbert