On Thu, Oct 22, 2020 at 11:14 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > On Thu, Oct 22, 2020 at 04:52:13PM +0300, Sergei Shtepa wrote: > > The 10/22/2020 13:28, Damien Le Moal wrote: > > > On 2020/10/22 18:43, Sergei Shtepa wrote: > > > > > > > > Maybe, but the problem is that I can't imagine how to implement > > > > dm-intercept yet. > > > > How to use dm to implement interception without changing the stack > > > > of block devices. We'll have to make a hook somewhere, isn`t it? > > > > > > Once your dm-intercept target driver is inserted with "dmsetup" or any user land > > > tool you implement using libdevicemapper, the "hooks" will naturally be in place > > > since the dm infrastructure already does that: all submitted BIOs will be passed > > > to dm-intercept through the "map" operation defined in the target_type > > > descriptor. It is then that driver job to execute the BIOs as it sees fit. > > > > > > Look at simple device mappers like dm-linear or dm-flakey for hints of how > > > things work (driver/md/dm-linear.c). More complex dm drivers like dm-crypt, > > > dm-writecache or dm-thin can give you hints about more features of device mapper. > > > Functions such as __map_bio() in drivers/md/dm.c are the core of DM and show > > > what happens to BIOs depending on the the return value of the map operation. > > > dm_submit_bio() and __split_and_process_bio() is the entry points for BIO > > > processing in DM. > > > > > > > Is there something I don't understand? Please correct me. > > > > Let me remind that by the condition of the problem, we can't change > > the configuration of the block device stack. > > > > Let's imagine this configuration: /root mount point on ext filesystem > > on /dev/sda1. > > +---------------+ > > | | > > | /root | > > | | > > +---------------+ > > | | > > | EXT FS | > > | | > > +---------------+ > > | | > > | block layer | > > | | > > | sda queue | > > | | > > +---------------+ > > | | > > | scsi driver | > > | | > > +---------------+ > > > > We need to add change block tracking (CBT) and snapshot functionality for > > incremental backup. > > > > With the DM we need to change the block device stack. Add device /dev/sda1 > > to LVM Volume group, create logical volume, change /etc/fstab and reboot. > > > > The new scheme will look like this: > > +---------------+ > > | | > > | /root | > > | | > > +---------------+ > > | | > > | EXT FS | > > | | > > +---------------+ > > | | > > | LV-root | > > | | > > +------------------+ > > | | > > | dm-cbt & dm-snap | > > | | > > +------------------+ > > | | > > | sda queue | > > | | > > +---------------+ > > | | > > | scsi driver | > > | | > > +---------------+ > > > > But I cannot change block device stack. And so I propose a scheme with > > interception. > > +---------------+ > > | | > > | /root | > > | | > > +---------------+ > > | | > > | EXT FS | > > | | > > +---------------+ +-----------------+ > > | | | | | > > | | blk-filter |-> | cbt & snapshot | > > | | |<- | | > > | +------------+ +-----------------+ > > | | > > | sda blk queue | > > | | > > +---------------+ > > | | > > | scsi driver | > > | | > > +---------------+ > > > > Perhaps I can make "cbt & snapshot" inside the DM, but without interception > > in any case, it will not work. Isn't that right? > > Stupid question: Why don't you change the block layer to make it > possible to insert device mapper devices after the blockdev has been set > up? Not a stupid question. Definitely something that us DM developers have wanted to do for a while. Devil is in the details but it is the right way forward. Otherwise, this intercept is really just a DM-lite remapping layer without any of DM's well established capabilities. Encouragingly, all of the replies have effectively echoed this point. (amusingly, seems every mailing list under the sun is on the cc except dm-devel... now rectified) Alasdair has some concrete ideas on this line of work; I'm trying to encourage him to reply ;) Mike
