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;
IronPort-SDR: BLkvs5GYlCrWf9O9fVM3AvutRlnDHoHj5Zu2ug7n+H1nP4RRGZfBEASbyYBYcv8ls4OVtZ0SAR
 XEZQFg6AnQdjjmuiZCJYstA7w2M0XN4FxDsTxaXtMX7YvBAjcyqlJ856HZo/aBMfdJlPmTWVoX
 OOnuaDMlqKIPFvQfvwfvCDYtnRJb3UiR+/FuImHTeLFvP7HmbgPY5VTFYr3BJgmOI1JPKs4kPt
 s2yEICfu0DNHZqNJmspfV+6hmgXozs2ARoNJVZNg0bY7QvYnBxL6fcahlTQtnDEFmq0aukH0qH
 PTQ=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Sergei Shtepa <sergei.shtepa@veeam.com>,
        "masahiroy@kernel.org" <masahiroy@kernel.org>,
        "michal.lkml@markovi.net" <michal.lkml@markovi.net>,
        "axboe@kernel.dk" <axboe@kernel.dk>,
        "koct9i@gmail.com" <koct9i@gmail.com>,
        "jack@suse.cz" <jack@suse.cz>,
        "ming.lei@redhat.com" <ming.lei@redhat.com>,
        "steve@sk2.org" <steve@sk2.org>,
        "linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH 0/1] block io layer filters api
Thread-Topic: [PATCH 0/1] block io layer filters api
Thread-Index: AQHWfKY6jwXCW96OpkCNOYh5TJLBhw==
Date:   Fri, 28 Aug 2020 07:24:30 +0000
Message-ID: <CY4PR04MB37518959789817D5CEE3E5AEE7520@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <1598555619-14792-1-git-send-email-sergei.shtepa@veeam.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 60f06d03-5e30-4dc2-5c38-08d84b236793
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 07:24:30.5884
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dFA1zgmh257Bh8Bv4BBLNJjlVEliwf6z58/Pzv7cCo3jj0Jr4mWw4dduk/bNMU9fp8nquperzEO1vfTupsz86A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB1256
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/08/28 4:14, Sergei Shtepa wrote:=0A=
> Hello everyone! Requesting for your comments and suggestions.=0A=
> =0A=
> We propose new kernel API that should be beneficial for out-of-tree=0A=
> kernel modules of multiple backup vendors: block layer filter API.=0A=
> =0A=
> Functionality:=0A=
> * Provide callback to intercept bio requests, the main purpose is to=0A=
> allow block level snapshots for the devices that do not support it,=0A=
> for example, non-LVM block devices and implementation of changed block=0A=
> tracking for faster incremental backups without system reconfiguration=0A=
> or reboot, but there could be other use cases that we have not thought of=
.=0A=
> * Allow multiple filters to work at the same time. The order in which the=
=0A=
> request is intercepted is determined by their altitude.=0A=
> * When new block devices appear, send a synchronous request to the=0A=
> registered filter to add it for filtering.=0A=
> * If a block device is permanently deleted or disappears, send a=0A=
> synchronous request to remove the device from filtering.=0A=
> =0A=
> Why dm-snap and dm-era is not the solution:=0A=
> Device mapper must be set up in advance, usually backup vendors have very=
=0A=
> little ability to change or convince users to modify the existing setup=
=0A=
> at the time of software installation.=0A=
> One of the most common setups is still a block device without LVM and=0A=
> formatted with ext4.=0A=
> Convincing users to redeploy or reconfigure machine, just to make block=
=0A=
> level snapshots/backup software work, is a challenging task.=0A=
=0A=
And convincing said users to change their kernel is not challenging ? In my=
=0A=
experience, that is even harder than trying to get them to change their=0A=
configuration.=0A=
=0A=
> As of now, commit c62b37d96b6e removed make_request_fn from=0A=
> struct request_queue and our out-of-tree module [1] can no longer=0A=
> hook/replace it to intercept bio requests. And fops in struct gendisk=0A=
> is declared as const and cannot be hooked as well.=0A=
> =0A=
> We would appreciate your feedback!=0A=
=0A=
Upstream your out-of-tree module ?=0A=
=0A=
> [1] https://github.com/veeam/veeamsnap=0A=
> =0A=
> Sergei Shtepa (1):=0A=
>   block io layer filters api=0A=
> =0A=
>  block/Kconfig               |  11 ++=0A=
>  block/Makefile              |   1 +=0A=
>  block/blk-core.c            |  11 +-=0A=
>  block/blk-filter-internal.h |  34 +++++=0A=
>  block/blk-filter.c          | 288 ++++++++++++++++++++++++++++++++++++=
=0A=
>  block/genhd.c               |  24 +++=0A=
>  include/linux/blk-filter.h  |  41 +++++=0A=
>  include/linux/genhd.h       |   2 +=0A=
>  8 files changed, 410 insertions(+), 2 deletions(-)=0A=
>  create mode 100644 block/blk-filter-internal.h=0A=
>  create mode 100644 block/blk-filter.c=0A=
>  create mode 100644 include/linux/blk-filter.h=0A=
> =0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=