[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [PATCH 1/1] dm-mpath: Extend path selectorinterface for supporting Dell EqualLogic path selector

Thanks, all, for the feedback.

We will update our proposed patch to pass individual parameters to the
selector instead of the entire struct request *, so it is compatible
either request-based or bio-based usage.  I do feel it makes sense to
a struct that will be passed through, now that we have more than just 
nr_bytes.  Mike, you have a  good point about not using a union, this
been removed.

> What other inputs - in addition to offset - will the path selector
need to take
> into account to make its decision and how will it get those inputs?
> Presumably you envisage some sort of semi-static or cached
> and not asking the hardware before every piece of I/O?
The additional parameters we would like to pass to the path selectors
-	Start address
-	Whether the IO is a read or write.  This will be stored in a
-	Timestamp of when the IO started, so the path selector can
the latency in end_io()

We understand the full path selector code is necessary before this patch

can be accepted, and will post it in the near future.

> How many ranges are there likely to be in this offset-based routing
> How frequently is the offset-based routing table likely to change?

> As Hannes points out, the dm table layer is already designed to handle
> offset-based routing, so I'll need some convincing there's a need to
> part of this inside path selectors.
> If this information is rapidly changing - many reconfigurations per
> then we may need to consider some in-kernel solution.  Otherwise I'll
> seeking solutions performing the reconfiguration from userspace first.

We agree with doing much of the work in userspace, such as reading the 
information from the storage array.  The routing table can change at any

time, but is not likely to be changing frequently, so a userspace
is adequate.  This information will be cached on the host so only a
lookup is necessary in the IO path.

There are many ranges in our routing table - when we spread data across
arrays in our group, each range is typically only 10s of MB, so it is
to have thousands of these ranges per LUN. 

Our initial design was to use a single entry in the dm table and a path 
selector that routed amongst paths based on the additional info proposed
Based on Alasdair's and Hannes' feedback we have done some
with the dm table layer offset based routing and it seems a viable
but we hit a couple of problems.  In the current kernel the DM is
rejecting our 
table - the multipath target is request based, and it seems the request
dm only supports tables that have a single target.  We have also tested
on an 
older kernel that uses a bio-based dm-multipath, and are able to load a
with dmsetup.  However, we seem to be bumping into a scalability limit
the table exceeds a few thousand lines.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]