I do not think we will end up with one super-terrific-optimal-for-all-workloads
path-selector. As result, people or vendors may wish to plug into dm-mpath and
use the exsiting dm path selectors. This is currently not possible because the
init funciotn and path status knowledge is stuck in the path-selector. Hey, that
was my fault so I will kick myself in the shins :) If we thought we will have a
single ps to rule them all then I guess we could add some way for vendors to
plug in there. However, as the subject of mail hints to the following patches
are based on the assumption stated at the beginning of the mail.
The goal of seperating out the priority_group stuff is so vendorX can implement
a pg or (internally) a collection of groups and define functions
like pg->init to send their failover commands or handle special
error cases. The latter is not really possible today becuase how to get, decode
and/pr pass vendor specific sense is not defined. Also, by seperatng the
HW specifics from the path-selection vendors can resuse dm's path-selectors.
01-sep-pg-from-mpath.patch - move some pg code out of dm-mpath.c. dm-mpath.c
still parses some args like how it does of selectors, but there is a new table
format:
num_groups [group-name num_group_args [selector-name num_selector_arg num_paths
[path_dev [path args (group args then selector args)]* ]+ ]+ ]+
The default group is just named "generic" and num_group_args=0.
02-sep-pg-from-ps.patch - moves the HW stuff out of the selector. Selector's are
once again notified of path status updates throught the update function.
03-add-modular-pg.patch - a place to put vendor specific junk. I will resend my
FAStT code ported to a priority-group, and seperate new group that should do the
failover for HP-storage-works.
Hey it says RFC, so please send ideas or comments good or bad.
Thanks,
Mike
