Hi all. I would like to discuss the idea of further extending the functionality of device mapper and suggest the concept of device filters (DF). The DM creates new block devices based on existing ones. DF will not create new devices. Using blk_interposer, DF will intercept bio requests, perform additional processing, and then pass (or skip) the original request. By analogy with the way DM implements various mapping algorithms through additional modules, so DF will be the basis for the work of modules that implement their own filtering algorithm. Based on DF, it will be possible to create solutions for live migration, continius data protection, and implement the backup on write algorithm. For security systems, it will be possible to implement algorithms for checking accesses to a block device. Installing and removing such filters does not require changing the configuration of the user's infrastructure or rebooting. Connecting and disconnecting is possible "on the fly" using blk-interposer. In this patch, I propose to consider additional IOCTL for the dm-mod module. The new IOCTL looks like a good starting point for developing device filters. It is technically possible to create a DF independently of the DM. However, I think that DF can use a significant part of the code already existing in the DM without creating duplication. I look forward to your feedback on device filter. Sergei Shtepa (1): dm: adds an IOCTL to work with device-filters drivers/md/Makefile | 2 +- drivers/md/dm-ioctl.c | 22 ++++++++++++++++++++++ drivers/md/flt-ctl.c | 25 +++++++++++++++++++++++++ drivers/md/flt-ctl.h | 10 ++++++++++ include/uapi/linux/dm-ioctl.h | 18 ++++++++++++++++-- 5 files changed, 74 insertions(+), 3 deletions(-) create mode 100644 drivers/md/flt-ctl.c create mode 100644 drivers/md/flt-ctl.h -- 2.20.1