Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Joe Thornber]

On Thu, Jul 25, 2002 at 12:36:45PM -0500, Ben Rafanello wrote:
> After a quick look through the device mapper code, it appears that
> device mapper knows nothing of the metadata format of the
> volumes/partitions/etc. that it is mapping.

This is deliberate, device-mapper maps devices, it does _not_ read 101
metadata formats.

With EVMS you have decided you want to read/write the metadata from
within the kernel.  That's fine, I think the jury's out at the moment
regarding whether the extra overhead of maintaining more kernel code
is offset by avoiding an initrd when placing root on an LV.

What I _do_ object to is that EVMS does not factor out seperate
interfaces/subsystems that can be used by appplications other than
EVMS.  This is why I say you are just embedding an application in the
kernel (as did LVM1), rather than providing a set of generic services.

> This will work well for
> cases where the metadata for the volume/volume group does not have to be
> updated at runtime.  However, it appears that device mapper needs a
> kernel module to handle those cases where the volume metadata must
> be updated during runtime (cases such as RAID 5, Mirroring -
> particularly the fancier forms with features like smart resync
> and hot spot mirroring, bad block relocation, etc.).

If you need to change the mapping all you have to do is suspend the
device, load a new map, and then unsuspend the device.  This can be
done from within the kernel, or from userland via the ioctl interface.

There is a facility enabling targets to notify userland processes of
events.  eg, a mirror has completed its initial sync, a bad block has
occured, etc.

> Thus, to
> support AIX (or any other enterprise level volume manager since
> they all tend to have similar features) would require more than
> "just a little bit of userland code", it would require a significant
> amount of kernel code as well.

No this can all be done from userland.

- Joe