Hello, I would like to ask the dm community whether our virtual block device driver would be better implemented as a dm target; whether this is in-line with the goals of the dm architecture, or constitutes abuse; and what exactly would be the gain for us to do so. 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? 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). 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 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? Thank you very much, Michael -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
