On Wed, Sep 11, 2002 at 02:37:40PM -0500, James Bottomley wrote:
> lmb@suse.de said:
> > and if the device mapper could have the notion of "to what topology
> > group does this device belong to", or even "distance metric (without
> > going into further detail on what this is, as long as it is consistent
> > to the physical layer) to the current CPU" (so that the shortest path
> > in NUMA could be selected), that would be kinda cool ;-) And doesn't
> > seem too intrusive.
>
> I think I see driverfs as the solution here. Topology is deduced by examining
> certain device and HBA parameters. As long as these parameters can be exposed
> as nodes in the device directory for driverfs, a user level daemon map the
> topology and connect the paths at the top. It should even be possible to
> weight the constructed multi-paths.
>
> This solution appeals because the kernel doesn't have to dictate policy, all
> it needs to be told is what information it should be exposing and lets user
> level get on with policy determination (this is a mini version of why we
> shouldn't have network routing policy deduced and implemented by the kernel).
Not coincidentally, network routing policy _is_ multipath config in
the iSCSI or nbd case.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:27 EST