Messages in this thread | | | Date | Fri, 19 Mar 2004 09:48:19 +0100 | From | Jens Axboe <> | Subject | Re: 2.6.4-mm2 |
| |
On Fri, Mar 19 2004, Andrew Morton wrote: > Jens Axboe <axboe@suse.de> wrote: > > > > On Fri, Mar 19 2004, Andrew Morton wrote: > > > Jens Axboe <axboe@suse.de> wrote: > > > > > > > > > Is it not the case that two dm maps can refer to the same queue? Say, one > > > > > map uses /dev/hda1 and another map uses /dev/hda2? > > > > > > > > > > If so, then when the /dev/hda queue is plugged we need to tell both the > > > > > higher-level maps that this queue needs an unplug. So blk_plug_device() > > > > > and the various unplug functions need to perform upcalls to an arbitrary > > > > > number of higher-level drivers, and those drivers need to keep track of the > > > > > currently-plugged queues without adding data structures to the > > > > > request_queue structure. > > > > > > > > > > It can be done of course, but could get messy. > > > > > > > > That would get nasty, it's much more natural to track it from the other > > > > end. I view it as a dm (or whatever problem) that they need to track who > > > > has pending io on their behalf, which is pretty easy to to from eg > > > > __map_bio(). > > > > > > But dm doesn't know enough. Suppose it is managing a map which includes > > > /dev/hda1 and I do some I/O against /dev/hda2 which plugs the queue. dm > > > needs to know about that plug. > > > > I don't follow at all. If dm initiates io against /dev/hda2, it's part > > of that mapped device and it can trigger and note the unplug just fine. > > Right. But suppose I have a plain old ext2 fs mounted on /dev/hda1. I do > some I/O against /dev/hda1, and that causes the /dev/hda queue to be > plugged. Device mapper doesn't know that the queue is currently plugged, > because it was some totally unrelated piece of code which caused the plug.
You are right, that breaks. No good.
-- 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/
| |