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
-
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:22 EST