Michael Keller [MKELLER@xxxxxxxxxx] wrote: > For our block-based incremental backup software we need to monitor all > writes to a device, and report them to our user mode application for > further processing. Our plan is to add a virtual block device of our own > "on top" of every block device to be monitored. Our driver then intercepts > all writes to this virtual device, executes the appropriate logic, and > eventually passes it on to the underlying device. > > Should we consider writing this as a dm target? > > Some points that came up in discussions with other folks: > 1. The "mapping" part itself is really trivial - it's an identity mapping. > Does this mean, we are really abusing the dm infrastructure? Don't think so. There are targets that have near 'identity mapping' (dm-delay) and multipath target will have 'identity mapping' too, apart from managing multiple paths! In general, dm targets process the I/O without the help of any user land code for performance. > 2. What are the actual gains from writing a dm target over writing a > dedicated driver? The following comes to mind: writing less setup code, a > user space library, tools (dmsetup). Yes. But then you will also get all the limitations/unimplemented features of device-mapper framework too. E.g. barrier support comes to mind! This is just an example, the simple barrier support might go to upstream before you actually begin using your target though. > 3. Are the interfaces of the device mapper relatively stable? (Assume that > our target is not general enough to be included into mainline, and we'll > have to do the API chasing ourselves.) I don't think API changes, if any, give you a big trouble. > I was also hoping that the device-mapper can somehow help us with > monitoring the device hosting the root filesystem. Device-mapper apparently > comes with some special support, which allows it to, e.g., mount root on a > logical volume. Does this work for any device-mapper targets, or just for > inbuilt ones? Where do you store the configuration information (dm tables) > anyway, so that it's accessible before root is mounted? As far as I know, "dm tables" are not stored persistently by the device mapper tools. LVM is the one that stores and uses it from initramfs/initrd. You will have to write your own tools to store the configuration and use it. These tools will have to be included in the initramfs/initrd for your thing to work on root device. You may need to reserve some space on the device to store your configuration! -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
