Hi Hannes,

On Tue, 11 Sep 2007 12:44:46 +0200, Hannes Reinecke <[EMAIL PROTECTED]> wrote:
> this is a proposal for a different implementation of request  
> callbacks. The existing ->endio callback of a request is actually a  
> destructor function, to be called to terminate a request and free all  
> structures.
> 
> However, on certain occasions (like request-based multipathing) it is  
> desirable to have a callback function for a request which is called  
> right after the request is finished, ie in end_that_request_first()  
> before any bio->bi_endio callback is called.
> 
> So a simple solution for this is to clone the request and add a new  
> 'marker' bio in front of the bio list of the request. This callback  
> will be attached a structure in bi_private which keeps a pointer to  
> the cloned and the original request, thus serving as a callback for  
> the request itself.

Thank you for another idea for request-based multipath.

However, I disagree with the idea.
I think the design (bio->bi_end_io() completes a request) is complex
a little bit and is breaking layer stacking.
Also, I think that the design of completion handling by 2 hooks,
bio->bi_end_io() and rq->end_io(), makes error handing in dm-multipath
complex.
e.g. Even if we detect an error on the first bio->bi_end_io() hook,
     the request can't be retried until the second rq->end_io() hook
     is called, because the ownership of the request is still on
     low level drivers until the low level driver calls
     end_that_request_last().


Although this is just implementation issue, I think that the patch
can't handle leftover.
SCSI, scsi_end_request(), may have some leftovers in the request.
Then, the marker bio is freed in bio->bi_end_io() and the request
is resubmitted in SCSI level.  So the resubmitted request
doesn't have the marker bio any more.

Thanks,
Kiyoshi Ueda
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to