From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46BA8C56201 for ; Thu, 22 Oct 2020 17:54:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C683B208B3 for ; Thu, 22 Oct 2020 17:54:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C683B208B3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 370A76B0070; Thu, 22 Oct 2020 13:54:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F8C56B0071; Thu, 22 Oct 2020 13:54:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C1496B0072; Thu, 22 Oct 2020 13:54:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0219.hostedemail.com [216.40.44.219]) by kanga.kvack.org (Postfix) with ESMTP id DFC586B0070 for ; Thu, 22 Oct 2020 13:54:29 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 76E70362B for ; Thu, 22 Oct 2020 17:54:29 +0000 (UTC) X-FDA: 77400311058.19.angle17_580db3127252 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 519E01ACEA2 for ; Thu, 22 Oct 2020 17:54:29 +0000 (UTC) X-HE-Tag: angle17_580db3127252 X-Filterd-Recvd-Size: 8143 Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Thu, 22 Oct 2020 17:54:28 +0000 (UTC) Received: by mail-pj1-f68.google.com with SMTP id m3so1364379pjf.4 for ; Thu, 22 Oct 2020 10:54:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jZuHlEwh3g7UcDcJaONWe8EfIxBYtT9I7AYk4QdFzwc=; b=XULBq6Xkg76h5A32MKaF7XMMm50iL3cK5hvABG8yqM1NNduI6vuwlhB/9R1DN8If0L gAiS/Ec4xAQQcrMD2Prv//l9qE2fwgguUOADjEZqEdRPxDPaDFHkKGaMXVXeUT5HO8iR j8f+J0uVdnBMdJloDBXJUeJRLqHjx0QBMjYzSsZNUio470hi9vJ4H5SR9yjHZKQP1Nd1 X5UP7o4TuMG9rLrwUXJF4yA/gJBNyOWkZ3iUF1wlI+MmQfiGXM83nYek5WtYUe9oIePj 383pHnoL40x3CSjFez4KPTcZ/b4mAITLpQlT9FnoYeGYvg0ywZrar0SsOuepQoaaSLwX QKUg== X-Gm-Message-State: AOAM532mcxNrME1iBgqIQN9dLobtqgS9jfYNpQCw1XUkb8SPYLND96C3 ihkj4NFwU1gOVP9+E0I3cVIAW7GHVlxHnSqsqlU= X-Google-Smtp-Source: ABdhPJxcm7nxDfpt8QtfKwOARuDT6nuFczBSIqDJ7vYnHyrPosWkJvFSDvOcbTMeVUL5SpoaDYnY4onxzd0QAP3w2Bs= X-Received: by 2002:a17:902:c254:b029:d4:c2d4:15f with SMTP id 20-20020a170902c254b02900d4c2d4015fmr3651304plg.18.1603389267970; Thu, 22 Oct 2020 10:54:27 -0700 (PDT) MIME-Version: 1.0 References: <1603271049-20681-1-git-send-email-sergei.shtepa@veeam.com> <71926887-5707-04a5-78a2-ffa2ee32bd68@suse.de> <20201021141044.GF20749@veeam.com> <20201022094402.GA21466@veeam.com> <20201022135213.GB21466@veeam.com> <20201022151418.GR9832@magnolia> In-Reply-To: <20201022151418.GR9832@magnolia> From: Mike Snitzer Date: Thu, 22 Oct 2020 13:54:16 -0400 Message-ID: Subject: Re: [PATCH 0/2] block layer filter and block device snapshot module To: "Darrick J. Wong" Cc: Sergei Shtepa , Damien Le Moal , Hannes Reinecke , "axboe@kernel.dk" , "viro@zeniv.linux.org.uk" , "hch@infradead.org" , "linux-xfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "akpm@linux-foundation.org" , Johannes Thumshirn , "ming.lei@redhat.com" , "jack@suse.cz" , "tj@kernel.org" , "gustavo@embeddedor.com" , "bvanassche@acm.org" , "osandov@fb.com" , "koct9i@gmail.com" , "steve@sk2.org" , "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , device-mapper development , Alasdair G Kergon Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 22, 2020 at 11:14 AM Darrick J. Wong wrote: > > On Thu, Oct 22, 2020 at 04:52:13PM +0300, Sergei Shtepa wrote: > > The 10/22/2020 13:28, Damien Le Moal wrote: > > > On 2020/10/22 18:43, Sergei Shtepa wrote: > > > > > > > > Maybe, but the problem is that I can't imagine how to implement > > > > dm-intercept yet. > > > > How to use dm to implement interception without changing the stack > > > > of block devices. We'll have to make a hook somewhere, isn`t it? > > > > > > Once your dm-intercept target driver is inserted with "dmsetup" or any user land > > > tool you implement using libdevicemapper, the "hooks" will naturally be in place > > > since the dm infrastructure already does that: all submitted BIOs will be passed > > > to dm-intercept through the "map" operation defined in the target_type > > > descriptor. It is then that driver job to execute the BIOs as it sees fit. > > > > > > Look at simple device mappers like dm-linear or dm-flakey for hints of how > > > things work (driver/md/dm-linear.c). More complex dm drivers like dm-crypt, > > > dm-writecache or dm-thin can give you hints about more features of device mapper. > > > Functions such as __map_bio() in drivers/md/dm.c are the core of DM and show > > > what happens to BIOs depending on the the return value of the map operation. > > > dm_submit_bio() and __split_and_process_bio() is the entry points for BIO > > > processing in DM. > > > > > > > Is there something I don't understand? Please correct me. > > > > Let me remind that by the condition of the problem, we can't change > > the configuration of the block device stack. > > > > Let's imagine this configuration: /root mount point on ext filesystem > > on /dev/sda1. > > +---------------+ > > | | > > | /root | > > | | > > +---------------+ > > | | > > | EXT FS | > > | | > > +---------------+ > > | | > > | block layer | > > | | > > | sda queue | > > | | > > +---------------+ > > | | > > | scsi driver | > > | | > > +---------------+ > > > > We need to add change block tracking (CBT) and snapshot functionality for > > incremental backup. > > > > With the DM we need to change the block device stack. Add device /dev/sda1 > > to LVM Volume group, create logical volume, change /etc/fstab and reboot. > > > > The new scheme will look like this: > > +---------------+ > > | | > > | /root | > > | | > > +---------------+ > > | | > > | EXT FS | > > | | > > +---------------+ > > | | > > | LV-root | > > | | > > +------------------+ > > | | > > | dm-cbt & dm-snap | > > | | > > +------------------+ > > | | > > | sda queue | > > | | > > +---------------+ > > | | > > | scsi driver | > > | | > > +---------------+ > > > > But I cannot change block device stack. And so I propose a scheme with > > interception. > > +---------------+ > > | | > > | /root | > > | | > > +---------------+ > > | | > > | EXT FS | > > | | > > +---------------+ +-----------------+ > > | | | | | > > | | blk-filter |-> | cbt & snapshot | > > | | |<- | | > > | +------------+ +-----------------+ > > | | > > | sda blk queue | > > | | > > +---------------+ > > | | > > | scsi driver | > > | | > > +---------------+ > > > > Perhaps I can make "cbt & snapshot" inside the DM, but without interception > > in any case, it will not work. Isn't that right? > > Stupid question: Why don't you change the block layer to make it > possible to insert device mapper devices after the blockdev has been set > up? Not a stupid question. Definitely something that us DM developers have wanted to do for a while. Devil is in the details but it is the right way forward. Otherwise, this intercept is really just a DM-lite remapping layer without any of DM's well established capabilities. Encouragingly, all of the replies have effectively echoed this point. (amusingly, seems every mailing list under the sun is on the cc except dm-devel... now rectified) Alasdair has some concrete ideas on this line of work; I'm trying to encourage him to reply ;) Mike