[dm-devel] RFC - new multi path scheduler - Striped

Burn Alting burn at goldweb.com.au
Thu Feb 21 10:42:15 UTC 2008


I'd like to propose a new multipath scheduler - striped.  The idea is
that, given a stripe size, S, we stripe the io in S block segments across
the available multiple paths.  If a path fails then a pre-determined
division of the stripe size reallocates which path gets the missing
paths data.

Taking the case of two paths and a stripe size of S blocks,

stripe number 0, blocks   0 thru   S - 1 goes via the first path;
stripe number 1, blocks   S thru 2*S - 1 goes via the second path;
stripe number 2, blocks 2*S thru 3*S - 1 goes via the first path and so forth.

If a path fails, then the surviving path gets all io.

Taking the general case of N paths and a stripe size of S blocks.

stripe number   0, blocks       0 thru   S - 1 goes via the first path
stripe number   1, blocks       S thru 2*S - 1 goes via the second path
stripe number   2, blocks     2*S thru 3*S - 1 goes via the third path
stripe number   3, blocks     3*S thru 4*S - 1 goes via the third path
stripe number N-1, blocks (N-1)*S thru N*S - 1 goes via the (N-1)th path
and so on

If a path fails, then we could say flush/drain all io's, redirect the
io's for the failed path to an adjacent path and then recompute the
stripe from N to N - 1 - ie keep the io balanced.


WHY?

For active-active multi-controller raid environments. I believe, if
we select an appropriate stripe size, then there would be minimal
interlock/cache clashes on the raid controllers and so we lessening
the chance of delay due to the raid controllers interlocking.

Raids tend to have a set stripe size, so the 'S' stripe size one would choose for
the multi-path driver would need to be a multiple of the raid controller's stripe size.

Can people comment on this?

Burn Alting





More information about the dm-devel mailing list