[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: Alasdair G Kergon <agk redhat com>
- To: device-mapper development <dm-devel redhat com>
- Cc: Parind Shah <Parind_Shah dell com>, Jason Shamberger <Jason_Shamberger dell com>, Narendran Ganapathy <Narendran_Ganapathy dell com>
- Subject: Re: [dm-devel] [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- Date: Mon, 12 Jul 2010 23:34:49 +0100
On Mon, Jun 28, 2010 at 09:53:20AM -0400, Narendran Ganapathy wrote:
> This patch extends the dm-path-selector interface to allow path selectors to
> use extra information from the IO request when selecting a path.
> To do location based routing, we need the address information of the request.
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 information,
and not asking the hardware before every piece of I/O?
How many ranges are there likely to be in this offset-based routing table?
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 duplicate
part of this inside path selectors.
If this information is rapidly changing - many reconfigurations per minute,
then we may need to consider some in-kernel solution. Otherwise I'll be
seeking solutions performing the reconfiguration from userspace first.
> We also propose extending the dm_mpath_io structure used to hold information
I'll consider proposals for any new fields alongside patches that make good use
of them, but I won't add fields in advance.
Alasdair
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]