I'm guessing you're referring to EVMS in that comment, since we have done *part* of what you just described. EVMS has always had a plugin to recognize MD devices, and has been using the MD driver for quite some time (along with using Device-Mapper for non-MD stuff). However, as of our most recent release (earlier this month), we switched to using Device-Mapper for MD RAID-linear and RAID-0 devices. Device-Mapper has always had a "linear" and a "striped" module (both required to support LVM volumes), and it was a rather trivial exercise to switch to activating these RAID devices using DM instead of MD.
This decision was not based on any real dislike of the MD driver, but rather for the benefits that are gained by using Device-Mapper. In particular, Device-Mapper provides the ability to change out the device mapping on the fly, by temporarily suspending I/O, changing the table, and resuming the I/O I'm sure many of you know this already. But I'm not sure everyone fully understands how powerful a feature this is. For instance, it means EVMS can now expand RAID-linear devices online. While that particular example may not[...]
As for not posting this information on lkml and/or linux-raid, I do apologize if this is something you would like to have been informed of. Most of the recent mentions of EVMS on this list seem to fall on deaf ears, so I've taken that to mean the folks on the list aren't terribly interested in EVMS developments. And since EVMS is a completely user-space tool and this decision didn't affect any kernel components, I didn't think it was really relevent to mention here. We usually discuss such things on evms-devel@xxxxxxxxxxxx or dm-devel@xxxxxxxxxx, but I'll be happy to cross-post to lkml more often if it's something that might be pertinent.
We're obviously pretty keen on seeing MD and Device-Mapper "merge" at some point in the future, primarily for some of the reasons I mentioned above. Obviously linear.c and raid0.c don't really need to be ported. DM provides equivalent functionality, the discovery/activation can be driven from user-space, and no in-kernel status updating is necessary (unlike RAID-1 and -5). And we've talked for a long time about wanting to port RAID-1 and RAID-5 (and now RAID-6) to Device-Mapper targets, but we haven't started on any such work, or even had any significant discussions about *how* to do it. I can't
imagine we would try this without at least involving Neil and other folks from linux-raid, since it would be nice to actually reuse as much of the existing MD code as possible (especially for RAID-5 and -6). I have no desire to try to rewrite those from scratch.
Device-Mapper does currently contain a mirroring module (still just in Joe's -udm tree), which has primarily been used to provide online-move functionality in LVM2 and EVMS. They've recently added support for persistent logs, so it's possible for a mirror to survive a reboot. Of course, MD RAID-1 has some additional requirements for updating status in its superblock at runtime. I'd hope that in porting RAID-1 to DM, the core of the DM mirroring module could still be used, with the possibility of either adding MD-RAID-1-specific information to the persistent-log module, or simply as an additional log type.