deferred sense

Quoted 4 lines · Christoph Hellwig

The kernel still doesn't hadle deferred sense correctly. In fact I'm not sure it's entirely possible to handle deferred sense correctly.

Quoted 2 lines

The iscsi driver variant of "translating" it to normal sense data and that for disks only certainly doesn't make much sense.

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.

Quoted 5 lines · Scott M. Ferris

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.

And I suspect we should get linux-scsi in the loop for the discussion about deferred sense handling.

Quoted 7 lines · Christoph Hellwig

Quoted 5 lines · Scott M. Ferris

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.

Quoted 2 lines

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.

Quoted 10 lines · James Bottomley

Quoted 8 lines · Christoph Hellwig

Quoted 5 lines · Scott M. Ferris

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.

Quoted 6 lines

Quoted 2 lines

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)

Quoted 30 lines · Tom Coughlan

Quoted 11 lines · James Bottomley

Quoted 9 lines · Christoph Hellwig

Quoted 5 lines · Scott M. Ferris

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 9 lines

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

Quoted 3 lines

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