Re: [RFC] libata new EH document

Luben Tuikov
2005-09-01T04:38:54Z

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