lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SYYP282MB1901AE0C3A06480BF8FA8A38B5D19@SYYP282MB1901.AUSP282.PROD.OUTLOOK.COM>
Date:   Wed, 1 Feb 2023 02:32:29 +0000
From:   Mason Giles <mason@...etbackup.com>
To:     Mike Snitzer <snitzer@...nel.org>,
        Sergei Shtepa <sergei.shtepa@...am.com>
CC:     "axboe@...nel.dk" <axboe@...nel.dk>,
        "corbet@....net" <corbet@....net>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>,
        "drwilliams@...to.com" <drwilliams@...to.com>
Subject: RE: [PATCH v2 00/21] blksnap - block devices snapshots module

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ