[lkml]   [2002]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [evms-devel] [linux-lvm] [ANNOUNCE] LVM reimplementation ready for beta testing
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...)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.118 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site