On Fri, Feb 01, 2002 at 03:59:06PM -0600, Kevin Corry wrote: > Current MD and LVM1: 11105 (this includes drivers/md, include/linux/lvm.h, > and include/linux/raid/) Why are you counting MD? It should be trivial to implement raid with device-mapper. > So I will agree - device-mapper does provide a nice, general-purpose I/O > remapping service in a small amount of code. It provides everything you need (from a kernel) to do Volume Management in general. (What's missing?) > And if you consider that EVMS has > implemented support for LVM1 and MD, then EVMS is really only adding 6580 > lines of code to the kernel. Yep, it's not the size, but the complexity. device-mapper is *simple*. It couldn't be simpler! simple is *good*, as long as it's not "too simple", in the sense that it doesn't get the job done. So, tell us what the disadvantages of device-mapper's "simplemindedness" is! > In this scenario, we would wind up with exposed devices for every item in > this graph (except the volume group). But in reality, we don't want someone > coming along and mucking with md0 or with LV2 or with any of the disk > partitions, because they are all in use by the two volumes at the top. It's the user's fault if they choose to write on such a device. > As we know, EVMS does volume discovery in the kernel. LVM1 does discovery in > user-space, but Joe has hinted at an in-kernel LVM1 discovery module to work > with device-mapper. Back when we started on EVMS, people were basically > shouting "we need in-kernel discovery!", Not me! Anyway, device-mapper is compatible with in-kernel discovery. But, why not just stick it in initramfs? (Are there any Issues?) > My belief is that it's the > kernel's job to tell user-space what the hardware looks like, not the other > way around. If we move partition/volume/etc discovery into user-space, at > what point do we move device recognition into user-space? There's a big difference: partition discovery isn't actually a hardware thing, it's a software thing. Some types of device recognition (iSCSI?) are also software things. WRT: beliefs, I think the kernel should provide all the services that can't be implemented well in userspace. > Looking down that > path just seems more and more like a micro-kernel approach, and I'm sure we > don't want to rehash that discussion. What's your point? > 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. Why do you need a single striping module? > How about mirroring? Does the linear module in device-mapper allow for 1-to-n > mappings? Wouldn't you use the strip module, with the chunk size set to a good approximation of infinity? Haven't tried it... Anyway, this is just a small detail... if there was no way of doing it, it would be easy to add a module... > So another device-mapper "module" > would need to be written to handle bad-block. This implicitly limits the > capabilities of device-mapper, or else ties it directly to the recognition > code. For EVMS and device-mapper to work together, we would have to agree on > metadata formats for these types of modules. Other similar example that come > to mind are RAID-5 and block-level encryption. Agreed... but these shouldn't be big problems? (raid-5 is already a standard...) Andrew _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
