Hi Christoph,
On 08/04/2010 03:51 AM +0900, Christoph Hellwig wrote:
> Adapt device-mapper to the new world order where even bio based devices
> get simple REQ_FLUSH requests for cache flushes, and need to submit
> them downwards for implementing barriers.
<snip>
> Index: linux-2.6/drivers/md/dm.c
> ===================================================================
> --- linux-2.6.orig/drivers/md/dm.c 2010-08-03 20:26:49.676004139 +0200
> +++ linux-2.6/drivers/md/dm.c 2010-08-03 20:36:59.301005325 +0200
<snip>
> @@ -1573,7 +1565,7 @@ static int dm_prep_fn(struct request_que
> struct mapped_device *md = q->queuedata;
> struct request *clone;
>
> - if (unlikely(dm_rq_is_flush_request(rq)))
> + if (rq->cmd_flags & REQ_FLUSH)
> return BLKPREP_OK;
>
> if (unlikely(rq->special)) {
> @@ -1664,7 +1656,7 @@ static void dm_request_fn(struct request
> if (!rq)
> goto plug_and_out;
>
> - if (unlikely(dm_rq_is_flush_request(rq))) {
> + if (rq->cmd_flags & REQ_FLUSH) {
> BUG_ON(md->flush_request);
> md->flush_request = rq;
> blk_start_request(rq);
Current request-based device-mapper's flush code depends on
the block-layer's barrier behavior which dispatches only one request
at a time when flush is needed.
In other words, current request-based device-mapper can't handle
other requests while a flush request is in progress.
I'll take a look how I can fix the request-based device-mapper to
cope with it. I think it'll take time for carefull investigation.
Thanks,
Kiyoshi Ueda
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
