--- Tejun Heo <htejun@xxxxxxxxx> wrote:
> As implementing autosensing will probably need rewriting failed qc
> for REQUEST SENSE command, I'm opposing it. My proposal is to do the
> following, which, in effect, should be equivalent to autosensing.
>
> 1. ATAPI CHECK SENSE occurs
> 2. libata fails the command
> 3. SCSI sees failure code but no sense data, SCSI EH invoked
> 4. libata EH invoked
> 5. REQUEST SENSE
> 6. sense data acquired
> 7. scsi_decide_disposition() called (this needs to be exported from SCSI)
> 8. libata handles the failed qc according to the verdict.
Hmm, yes. It sounds good, except can you make it so that step 3
doesn't exist, ever. This means that you would _reduce_ the
double "bouncing" between eh's _and_ implement autosense.
SCSI Core should never know what happened. I.e. if the command
has completed with CHECK SENSE, sense data _is_ present => "autosense".
> This is very similar to what SCSI EH currently does for commands
> without sense data.
Yes, you're right -- it is very similar to what SCSI EH currently does.
Unfortunately it isn't quite correct.
> As ATAPI device's queue depth is always one (ignoring SERVICE cruft
> everyone seems to hate), I don't think there will be any noticeable
> performance penalty as James was describing in the other mail in this
> thread.
What you can do is keep a qc around to request sense immediately
afterwards. If _that_ qc fails, then you know you need the big hammer.
Luben
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
