Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Sergei Shtepa <sergei.shtepa@veeam.com>
To:     <masahiroy@kernel.org>, <michal.lkml@markovi.net>,
        <axboe@kernel.dk>, <koct9i@gmail.com>, <jack@suse.cz>,
        <damien.lemoal@wdc.com>, <ming.lei@redhat.com>, <steve@sk2.org>,
        <linux-kbuild@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-block@vger.kernel.org>
CC:     Sergei Shtepa <sergei.shtepa@veeam.com>
Subject: [PATCH 0/1] block io layer filters api
Date:   Thu, 27 Aug 2020 22:13:38 +0300
Message-ID: <1598555619-14792-1-git-send-email-sergei.shtepa@veeam.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello everyone! Requesting for your comments and suggestions.

We propose new kernel API that should be beneficial for out-of-tree
kernel modules of multiple backup vendors: block layer filter API.

Functionality:
* Provide callback to intercept bio requests, the main purpose is to
allow block level snapshots for the devices that do not support it,
for example, non-LVM block devices and implementation of changed block
tracking for faster incremental backups without system reconfiguration
or reboot, but there could be other use cases that we have not thought of.
* Allow multiple filters to work at the same time. The order in which the
request is intercepted is determined by their altitude.
* When new block devices appear, send a synchronous request to the
registered filter to add it for filtering.
* If a block device is permanently deleted or disappears, send a
synchronous request to remove the device from filtering.

Why dm-snap and dm-era is not the solution:
Device mapper must be set up in advance, usually backup vendors have very
little ability to change or convince users to modify the existing setup
at the time of software installation.
One of the most common setups is still a block device without LVM and
formatted with ext4.
Convincing users to redeploy or reconfigure machine, just to make block
level snapshots/backup software work, is a challenging task.

As of now, commit c62b37d96b6e removed make_request_fn from
struct request_queue and our out-of-tree module [1] can no longer
hook/replace it to intercept bio requests. And fops in struct gendisk
is declared as const and cannot be hooked as well.

We would appreciate your feedback!

[1] https://github.com/veeam/veeamsnap

Sergei Shtepa (1):
  block io layer filters api

 block/Kconfig               |  11 ++
 block/Makefile              |   1 +
 block/blk-core.c            |  11 +-
 block/blk-filter-internal.h |  34 +++++
 block/blk-filter.c          | 288 ++++++++++++++++++++++++++++++++++++
 block/genhd.c               |  24 +++
 include/linux/blk-filter.h  |  41 +++++
 include/linux/genhd.h       |   2 +
 8 files changed, 410 insertions(+), 2 deletions(-)
 create mode 100644 block/blk-filter-internal.h
 create mode 100644 block/blk-filter.c
 create mode 100644 include/linux/blk-filter.h

-- 
2.20.1