[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] 2.6.10-rc1-udm1: multipath work in progress
- From: Alasdair G Kergon <agk redhat com>
- To: device-mapper development <dm-devel redhat com>
- Subject: Re: [dm-devel] 2.6.10-rc1-udm1: multipath work in progress
- Date: Mon, 8 Nov 2004 21:43:31 +0000
On Mon, Nov 08, 2004 at 05:56:14PM +0100, Lars Marowsky-Bree wrote:
> Probably doesn't need to be exported, but to avoid the potential
> infinite ping-pong between the PGs it's probably still needed as
> Alasdair pointed out.
Restating this:
A PG can be asked to initialise in two ways - say politely and rudely.
If you ask it politely it is allowed to respond saying "It would be best
if you asked the other PGs politely first - but ask me again rudely if
none of them take ownership and then I might be able to but with the
risk of a performance hit." [We record this response by setting
the 'bypass' flag against that PG.]
If you call it rudely, that response isn't allowed: it must either
initialise the path and start accepting I/O or else fail the path.
We ask each PG politely in priority order - then if necessary we ask
them all again rudely. If we still don't have a path, we either error
the I/O or we queue it and wait for guidance from userspace, depending
whether or not 'queue_if_no_path' is set. If userspace suspends the
table (e.g. to load a new one) any I/O queued in this way gets EIO.
But userspace can have it retried by reenabling paths. (NB The
order matters: the first path reenabled will get retried immediately,
implicitly switching to the first PG it's in.)
Once a PG is accepting I/O, all I/O continues going to that PG until:
all its paths fail; or
it asks to be bypassed in response to an error; or
userspace sends a 'switch_group' message to switch to another PG.
Alasdair
--
agk redhat com
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]