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
-
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 : Tue Jul 30 2002 - 14:00:23 EST