Messages in this thread |  | | Date | Wed, 11 Sep 2002 16:38:11 -0500 | From | Oliver Xymoron <> | Subject | Re: [RFC] Multi-path IO in 2.5/2.6 ? |
| |
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/
|  |