| Age | Commit message (Collapse) | Author |
|---|
|
path when talking to an array until it goes away, then you fail
over to the next active path.
im using this to talk to ses(4) in my dell, and allows us to support
arrays that have multiple controllers but have no way of reporting
which one is active. using the MRU semantic means we can talk to
them without them flipping the active role between its controllers
all the time. claudios transtec iscsi box is like this.
|
|
that's ever used it, and it's long since been changed to use
DVACT_{QUIESCE,SUSPEND,RESUME} instead.
ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it
up a few weeks ago
|
|
|
|
|
|
their start routines, they dont have to pass pointers to them in the
ops struct.
|
|
|
|
required this.
requested by deraadt@
|
|
the big change is how paths between mpath capable devices and the
kernel are managed.
originally the midlayer would steal the links to the devices and
hide them behind mpath. all the changes an adapter made to a link
(eg activate or detach), the midlayer had to test if it was an mpath
link and then call special mpath code to handle it.
the original code also assumed that all paths behaved the same, but
the reality is that different devices have different command sets
and behaviours. figuring out which behaviour to pick and prioritising
them is basically the same job autoconf does with match and attach.
rather than special casing mpath in the midlayer and reimplimenting
autoconf, this turns paths into actual device drivers with match
and attach routines. after they figure out if the path is active,
they then give it to mpath(4) to use as a backend.
i have written drivers for symmetric access devices (sym(4)) where
all paths to the same logical unit are as good as each other,
lsi/engenio arrays (rdac(4), and emc arrays (emc(4)).
the rdac and emc drivers only detect active paths at attach time,
the do not cope if the controller changes state unless you unplug
the path and plug it in again to retest the active state. they also
do not have support for directing array failover.
operating and hoplugging has been tested with mpii(4), fc and sas
mpi(4), and iscsi via vscsi (claudio did this too).
ok krw@ deraadt@
|
