Messages in this thread | | | Date | Fri, 26 Jul 2002 09:16:14 +0100 | Subject | Re: [2.6] Most likely to be merged by Halloween... THE LIST | From | 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 - 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/
| |