Hi Mike and Sergei, > > It’s not about Veeam at all. I am sure that my work will help many > > backup vendors and average users to build more robust and efficient backup > > tools. > > So, the argument that I do it just because Veeam needs it does not > > hold any water – I know that many people need the feature, not just Veeam. > > No other snapshot consumers have shown themselves. Using them as some sort of > implied consensus on what is needed for generic Linux snapshot is a bit of a > leap. All you really have are your requirements. Doesn't really help to say > you represent the interests of all interested parties if they remain nameless > and in the background.
I'm speaking on behalf of Comet Backup, another commercial vendor in this space. I just want to chime in and say we're very closely following the development of this patch set. Our end-user customers have an "arbitrary" Linux system where we don't control the filesystem or block device layer. Having a point-in-time consistent snapshot is essential for a high quality backup, and it's table-stakes on Windows with the VSS subsystem. But a very large number of installs in-the-wild are using plain ext4 without lvm, and we have no remaining viable mechanisms for either filesystem-level or block device-level backup. For this use case, the snapshots are generally short-lived. The underlying mechanism doesn't affect us much - whether it's live-swapping DM devices, or explicitly tracking bio's (or if somehow ext4 and xfs magically got fs-level snapshotting support). But most of all, we'd love to see something upstream. I'd also point you towards Datto's out-of-tree 'dattobd' block device driver with the same objective: https://github.com/datto/dattobd (LGPLv2+). It was working in a slightly different way by using ftrace to hook submit_bio_noacct. Regards, Mason Giles -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
