On 10/21/20 4:10 PM, Sergei Shtepa wrote:
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.
Actually, once we have an dm-intercept, why do you need the block-layer
filter at all?
From you initial description the block-layer filter was implemented
such that blk-snap could work; but if we have dm-intercept (and with it
the ability to use device-mapper functionality even for normal block
devices) there wouldn't be any need for the block-layer filter, no?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
