The 10/21/2020 16:31, Hannes Reinecke wrote: > I do understand where you are coming from, but then we already have a > dm-snap which does exactly what you want to achieve. > Of course, that would require a reconfiguration of the storage stack on > the machine, which is not always possible (or desired). Yes, reconfiguring the storage stack on a machine is almost impossible. > > What I _could_ imagine would be a 'dm-intercept' thingie, which > redirects the current submit_bio() function for any block device, and > re-routes that to a linear device-mapper device pointing back to the > original block device. > > That way you could attach it to basically any block device, _and_ can > use the existing device-mapper functionality to do fancy stuff once the > submit_io() callback has been re-routed. > > And it also would help in other scenarios, too; with such a > functionality we could seamlessly clone devices without having to move > the whole setup to device-mapper first. Hm... Did I understand correctly that the filter itself can be left approximately as it is, but the blk-snap module can be replaced with 'dm-intercept', which would use the re-route mechanism from the dm? I think I may be able to implement it, if you describe your idea in more detail. -- Sergei Shtepa Veeam Software developer.
