[lkml]   [2002]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Multi-path IO in 2.5/2.6 ?
On Wed, Sep 11, 2002 at 02:37:40PM -0500, James Bottomley wrote:
> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.823 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site