From: Mason Giles <mason@cometbackup.com>
To: Mike Snitzer <snitzer@kernel.org>,
Sergei Shtepa <sergei.shtepa@veeam.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
"corbet@lwn.net" <corbet@lwn.net>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"drwilliams@datto.com" <drwilliams@datto.com>
Subject: RE: [PATCH v2 00/21] blksnap - block devices snapshots module
Date: Wed, 1 Feb 2023 02:32:29 +0000 [thread overview]
Message-ID: <SYYP282MB1901AE0C3A06480BF8FA8A38B5D19@SYYP282MB1901.AUSP282.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <Y9l+WIDSrVhRhPME@redhat.com>
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
prev parent reply other threads:[~2023-02-01 2:32 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 14:23 [PATCH v2 00/21] blksnap - block devices snapshots module Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 01/21] documentation, blkfilter: Block Device Filtering Mechanism Sergei Shtepa
2022-12-10 4:15 ` Bagas Sanjaya
2022-12-09 14:23 ` [PATCH v2 02/21] block, " Sergei Shtepa
2022-12-15 9:26 ` Christoph Hellwig
2022-12-15 10:46 ` Sergei Shtepa
2022-12-16 7:04 ` Christoph Hellwig
2023-01-31 23:58 ` Mike Snitzer
2023-02-01 11:09 ` Fabio Fantoni
2023-02-01 13:16 ` Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 03/21] documentation, capability: fix Generic Block Device Capability Sergei Shtepa
2022-12-13 12:13 ` Fabio Fantoni
2022-12-30 15:35 ` Fabio Fantoni
2022-12-09 14:23 ` [PATCH v2 04/21] documentation, blksnap: Block Devices Snapshots Module Sergei Shtepa
2022-12-10 3:50 ` Bagas Sanjaya
2022-12-09 14:23 ` [PATCH v2 05/21] block, blksnap: header file of the module interface Sergei Shtepa
2022-12-09 22:13 ` kernel test robot
2022-12-09 23:14 ` kernel test robot
2022-12-09 14:23 ` [PATCH v2 06/21] block, blksnap: module management interface functions Sergei Shtepa
2022-12-15 9:28 ` Christoph Hellwig
[not found] ` <CGME20230103153406eucas1p205c48bd767e6a86f6f1121db7eb5fc19@eucas1p2.samsung.com>
2023-01-03 15:26 ` Pankaj Raghav
2022-12-09 14:23 ` [PATCH v2 07/21] block, blksnap: init() and exit() functions Sergei Shtepa
2022-12-15 9:30 ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 08/21] block, blksnap: interaction with sysfs Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 09/21] block, blksnap: attaching and detaching the filter and handling I/O units Sergei Shtepa
2022-12-15 10:01 ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 10/21] block, blksnap: map of change block tracking Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 11/21] block, blksnap: minimum data storage unit of the original block device Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 12/21] block, blksnap: buffer in memory for the minimum data storage unit Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 13/21] block, blksnap: functions and structures for performing block I/O operations Sergei Shtepa
2022-12-15 10:06 ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 14/21] block, blksnap: storage for storing difference blocks Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 15/21] block, blksnap: event queue from the difference storage Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 16/21] block, blksnap: owner of information about overwritten blocks of the original block device Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 17/21] block, blksnap: snapshot image " Sergei Shtepa
2022-12-15 9:45 ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 18/21] block, blksnap: snapshot Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 19/21] block, blksnap: Kconfig and Makefile Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 20/21] block, blksnap: adds a blksnap to the kernel tree Sergei Shtepa
2022-12-09 21:53 ` kernel test robot
2022-12-09 14:23 ` [PATCH v2 21/21] block, blksnap: adds a maintainer for new files Sergei Shtepa
2022-12-10 3:23 ` [PATCH v2 00/21] blksnap - block devices snapshots module Bagas Sanjaya
2022-12-10 22:57 ` Sergei Shtepa
[not found] ` <20230101071813.3329-1-hdanton@sina.com>
2023-01-02 9:44 ` [PATCH v2 17/21] block, blksnap: snapshot image block device Sergei Shtepa
[not found] ` <20230101110542.3395-1-hdanton@sina.com>
2023-01-02 9:58 ` [PATCH v2 18/21] block, blksnap: snapshot Sergei Shtepa
2023-01-17 21:04 ` [PATCH v2 00/21] blksnap - block devices snapshots module Mike Snitzer
2023-01-18 10:51 ` Hannes Reinecke
2023-01-24 11:34 ` Sergei Shtepa
2023-01-31 20:47 ` Mike Snitzer
2023-02-01 2:32 ` Mason Giles [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SYYP282MB1901AE0C3A06480BF8FA8A38B5D19@SYYP282MB1901.AUSP282.PROD.OUTLOOK.COM \
--to=mason@cometbackup.com \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=dm-devel@redhat.com \
--cc=drwilliams@datto.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sergei.shtepa@veeam.com \
--cc=snitzer@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).