Re: [RFC] libata new EH document

[Luben Tuikov <ltuikov@yahoo.com>]

--- Tejun Heo <htejun@gmail.com> 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