[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110405130541.6c2b5f86@notabene.brown>
Date: Tue, 5 Apr 2011 13:05:41 +1000
From: NeilBrown <neilb@...e.de>
To: Mike Snitzer <snitzer@...hat.com>
Cc: Jens Axboe <jaxboe@...ionio.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"hch@...radead.org" <hch@...radead.org>, dm-devel@...hat.com
Subject: Re: [PATCH 05/10] block: remove per-queue plugging
On Wed, 9 Mar 2011 19:58:10 -0500 Mike Snitzer <snitzer@...hat.com> wrote:
> Also, in your MD changes, you removed all calls to md_unplug() but
> didn't remove md_unplug(). Seems it should be removed along with the
> 'plug' member of 'struct mddev_t'? Neil?
I've been distracted by other things and only just managed to have a look at
this.
The new plugging code seems to completely ignore the needs of stacked devices
- or at least my needs in md.
For RAID1 with a write-intent-bitmap, I queue all write requests and then on
an unplug I update the write-intent-bitmap to mark all the relevant blocks
and then release the writes.
With the new code there is no way for an unplug event to wake up the raid1d
thread to start the writeout - I haven't tested it but I suspect it will just
hang.
Similarly for RAID5 I gather write bios (long before they become 'struct
request' which is what the plugging code understands) and on an unplug event
I release the writes - hopefully with enough bios per stripe so that we don't
need to pre-read.
Possibly the simplest fix would be to have a second list_head in 'struct
blk_plug' which contained callbacks (a function pointer a list_head in a
struct which is passed as an arg to the function!).
blk_finish_plug could then walk the list and call the call-backs.
It would be quite easy to hook into that.
I suspect I also need to add blk_start_plug/blk_finish_plug around the loop
in raid1d/raid5d/raid10d, but that is pretty straight forward.
Am I missing something important?
Is there a better way to get an unplug event to md?
Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists