[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

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.

agk redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]