Block-device snapshots with blksnap

Posted Nov 15, 2022 6:03 UTC (Tue) by donald.buczek (subscriber, #112892)
Parent article: Block-device snapshots with blksnap

It doesn't feel right to have a second complex system to redirect block i/o into.

Why not build on the dm system? Instead of the new system, we'd only need the ability to attach a dm device to an existing block device. And we'd need to allow a mounted block device as a dm target, which, I think, is currently prevented without the option to override.

Block-device snapshots with blksnap

Posted Nov 15, 2022 13:03 UTC (Tue) by Conan_Kudo (subscriber, #103240) [Link] (7 responses)

This is something that I've explored before when talking to the DM folks before and after dattobd was written. The plain and simple truth is that they don't want to. The DM folks believe that the users should just redo their storage from scratch if they want the capabilities of DM and any other way is foolhardy at best. After a bunch of circular discussions, I gave up.

Sometimes I wonder if some of the Linux subsystem maintainers have actually worked in real-world situations before, because I get some pretty asinine suggestions sometimes...

Block-device snapshots with blksnap

Posted Nov 15, 2022 15:41 UTC (Tue) by Wol (subscriber, #4433) [Link]

If they've never worked outside of a computer department, if they've never lived in the end-user world, then they're like politicians - they know how things SHOULD be done, they've just never tried to do it, and they're surprised when the "should" is totally impractical or counter-productive.

The mainframe culture writ large in the IT department ...

Cheers,
Wol

Block-device snapshots with blksnap

Posted Nov 15, 2022 16:04 UTC (Tue) by donald.buczek (subscriber, #112892) [Link] (4 responses)

> dattobd

Oh, wow, impressive work.

I can see, you'd rather have a more stable interface for you hooks than ftrace.

> blk_qc_t (*dattobd_submit_bio_noacct_passthrough)(struct bio *) =
> (blk_qc_t(*)(struct bio *))((unsigned long)(submit_bio_noacct) +
> FENTRY_CALL_INSTR_BYTES);

Another idea to avoid ftrace patch recursion, thanks :-)

Block-device snapshots with blksnap

Posted Nov 15, 2022 16:22 UTC (Tue) by Conan_Kudo (subscriber, #103240) [Link]

There was a hot minute where I was aggressively trying to push for upstreaming dattobd into Linux (we even had the generic name for it picked out: "volsnap"), but the amount of negative feedback we got about it in 2017 killed that stone cold. It was pretty depressing...

Block-device snapshots with blksnap

Posted Nov 15, 2022 23:51 UTC (Tue) by sshtepa (guest, #158959) [Link] (2 responses)

One problem is that it only works on Intel/AMD architecture.
I haven't been able to do something similar for ARM or POWER yet.
If you have any ideas how to fix it, let me know :).

Block-device snapshots with blksnap

Posted Nov 16, 2022 7:35 UTC (Wed) by donald.buczek (subscriber, #112892) [Link] (1 responses)

> If you have any ideas how to fix it, let me know :).

This is not my idea, but one method is to accept and detect the recursion [1]. But the additional stack frame and overhead is something you possibly don't want to have in the submit_bio path.

[1]: https://github.molgen.mpg.de/mariux64/fix-lpp/blob/e4c41a...

Block-device snapshots with blksnap

Posted Nov 17, 2022 16:30 UTC (Thu) by sshtepa (guest, #158959) [Link]

Unfortunately, in order to be able to work on existing Linux kernels, I have to use such disgusting crutches.
Offering a module to the upstream is a solution to this problem. And many other problems.

Block-device snapshots with blksnap

Posted Jan 17, 2023 18:39 UTC (Tue) by msnitzer (subscriber, #57232) [Link]

As the DM subsystem maintainer I don't recall you ever directly or indirectly contacting me (famous last words). But I've _never_ been opposed to devising a way to make all block devices capable of being remapped without first needing to have created the DM device at the dawn of time.

The need for such a capability is quite niche... but I don't dispute that those who would like it exist (and might jump to false accusations about others :/ ).

The coding of such an advance just hasn't been a priority _for me or my broader team within Red Hat_. That doesn't mean "DM folks" reject the idea. It means others need to do the work. Implementing it in terms of yet another way to remap IO (blkfilter) speaks to inherent lack of understanding on how to make a general purpose advance that doesn't further splinter the block core's capabilities.

Block-device snapshots with blksnap

Posted Nov 16, 2022 8:04 UTC (Wed) by donald.buczek (subscriber, #112892) [Link] (2 responses)

My criticism was unjustified. The patch series contains a new general mechanism to hook into the i/o path of an existing block device and such a mechanism doesn't currently exist. blksnap would just be one potential user of it. And the article says so.

But then I wonder if it would possible to add a filter module which redirects into a dm stack.

Block-device snapshots with blksnap

Posted Nov 17, 2022 17:33 UTC (Thu) by sshtepa (guest, #158959) [Link] (1 responses)

Technically, this is certainly possible. Moreover, I tried to make just such a blk-interposer for DM. I even had a working code (verified by the developer ;-).
But interaction with Mike on this work turned out to be ... mmmmm, not effective. Сan be many reasons for this. Perhaps the DM team is busy with higher priority tasks. I think that in order to add a filter to the existing DM architecture we will have to redo quite a lot of code. This requires the will of the DM developers.

Block-device snapshots with blksnap

Posted Jan 17, 2023 19:23 UTC (Tue) by msnitzer (subscriber, #57232) [Link]

As I just stated elsewhere in this LWN thread. I haven't had a need for this capability. The blkinterposer work seemed on its way. I guess you felt my lack of direct ownership personal. But iterating on things is how Linux is developed.

Working around the removal of a key export that the veeam team was (ab)using to hijack IO for their commerical backup product by introducing yet another mechanism to remap IO is certainly one way to proceed -- but it sure isn't the most productive way to advance Linux's existing capabilities without splintering our collective efforts.

I suppose I should've taken on working on something for some other company's benefit simply because I happen to work on and maintain DM? Pretty specious logic there.