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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
