On Fri, Feb 01, 2002 at 03:59:06PM -0600, Kevin Corry wrote:
> I have been thinking about this today and looking over some of the
> device-mapper interfaces. I will agree that, in concept, EVMS could be
> modified to use device-mapper for I/O remapping. However, as things stand
> today, I don't think the transition would be easy.
>
> As I'm trying to envision it, the EVMS runtime would become a "volume
> recognition" framework (see tanget below). Every current EVMS plugin would
> then probe all available devices and communicate the necessary volume
> remapping info to device-mapper through the ioctl interface. (An in-kernel
> API set might be nice to avoid the overhead of the ioctl path).
The in kernel API already exists in drivers/md/dm.h, see dm-ioctl.c
for example code that uses this.
> A new device would then be created for every node that every plugin
> recognizes. This brings up my first objection. With this approach,
> there would be an exposed device for every node in a volume stack,
> whereas the current EVMS design only exposes nodes for the final
> volumes.
True, all the devices are exposed in /dev/device-mapper. What we do
with LVM2 is stick with the /dev/<vg_name>/<lv_name> scheme, where the
lv is a symlink to the relevant node in the device-mapper dir. That
way people only see the top level devices, unless they peek under the
hood by looking at /dev/device-mapper.
> Next, from what I've seen, device-mapper provides static remappings
> from one device to another. It seems to be a good approach for
> setting up things like disk partitions and LVM linear LVs. There is
> also striping support in device-mapper, but I'm assuming it uses one
> notion of striping. For instance, RAID-0 striping in MD is handled
> differently than striped LVs in LVM, and I think AIX striping is
> also different. I'm not sure if one stiping module could be generic
> enough to handle all of these cases. But, maybe it can. I'll have to
> think more about that one.
The thing that you've missed is that ranges of sectors are mapped by
dm onto 'targets', these targets are instances of a 'target_type'
virtual class. You can define your own target types in a seperate
module and register them using the
int dm_register_target(struct target_type *t);
function (see <linux/device-mapper.h>). We originally intended all
the standard target types to be defined in seperate modules, but that
seemed silly considering the tiny size of them (eg, < 200 lines for striping).
The targets type that we will be using in LVM2 are:
io-err - errors every io
linear
striped
snapshot, and snapshot origin
mirror (used to provide pvmove support as well as mirroring).
(both the snapshot targets and mirroring target will use kcopyd for
efficient copying using kiobufs.)
So if you invent a new form of striping, just implement a new target type.
> How about mirroring? Does the linear module in device-mapper allow
> for 1-to-n mappings? This would be similar to the way AIX does
> mirroring, where each LP of an LV can map to up to three PPs on
> different PVs.
No, there's a seperate mirror target that Patrick Caulfields working
on at the moment.
> How would device-mapper handle a remapping that is dynamic at runtime?
Suspending a device flushes all pending io to the device, ie. all io
that has been through the driver but not yet completed. Once you have
suspended you are free to loaded a new mapping table into the device
(this is essential for implementing snapshots and pvmove). When the
new mapping is in place you just have to resume the device and away
you go.
- Joe
-
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 : Thu Feb 07 2002 - 21:00:27 EST