Re: [PATCH] libata error handling fixes (ATAPI)

[Jens Axboe <axboe@suse.de>]

On Tue, Nov 15 2005, Jeff Garzik wrote:
> >For departure of libata from SCSI, I was thinking more of another more 
> >generic block device framework in which libata can live in.  And I 
> >thought that it was reasonable to assume that the framework would supply 
> >a EH mechanism which supports queue stalling/draining and separate 
> >thread.  So, my EH patches tried to make the same environment for libata 
> 
> A big reason why libata uses the SCSI layer is infrastructure like this. 
>  It would certainly be nice to see timeouts and EH at the block layer. 
>  The block layer itself already supports queue stalling/draining.

I have a pretty simple plan for this:

- Add a timer to struct request. It already has a timeout field for
  SG_IO originated requests, we could easily utilize this in general.
  I'm not sure how the querying of timeout would happen so far, it would
  probably require a q->set_rq_timeout() hook to ask the low level
  driver to set/return rq->timeout for a given request.

- Add a timeout hook to struct request_queue that would get invoked from
  the timeout handler. Something along the lines of:

        - Timeout on a request happens. Freeze the queue and use
          kblockd to take the actual timeout into process context, where
          we call the queue ->rq_timeout() hook. Unfreeze/reschedule
          queue operations based on what the ->rq_timeout() hook tells
          us.

That is generic enough to be able to arm the timeout automatically from
->elevator_activate_req_fn() and dearm it when it completes or gets
deactivated. It should also be possible to implement the SCSI error
handling on top of that.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/