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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D179CC4332F for ; Thu, 29 Dec 2022 08:22:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230380AbiL2IWu (ORCPT ); Thu, 29 Dec 2022 03:22:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230193AbiL2IWp (ORCPT ); Thu, 29 Dec 2022 03:22:45 -0500 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E7C46470 for ; Thu, 29 Dec 2022 00:22:44 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id b88so18529979edf.6 for ; Thu, 29 Dec 2022 00:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cdbk6YKET6QEGq9IebYDQMQPZF6j/6rc109njHhKlvI=; b=e0zqBtvvlQD2HeN7X7P1SHKwtY1WmNXBewHhrqgYf+Cjes2XV0RT3hygT/cZ9mLgAg mK9seVibJbFJISY9ylAm9410ISVQog0mR5lB7brL/TzMXjDdvh0jGSUofBvfksQXdS0N Bc48MzAHtkmpJ07DAwIqs27Z+Q8lD/rkRbbfs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cdbk6YKET6QEGq9IebYDQMQPZF6j/6rc109njHhKlvI=; b=DKrMbBpZytXBLjAUh8xoImhAWArjcGGzEToncn0QuodLe4tyou6XgH6H5wuxw76SZk Z4eHOgvTOC3aAkAeLMz2MSdsC36GChSbtVsKVQpQNumv5eypPGwBdTj4FEIGf33tqJt1 9ZPSqW33DNfn4irKmzedEQTPThM7U/Ye6c/M6pN4UvdchoHeqcoCJCErxo6wou8LZvGZ 0jtTqLth3GP3559tcm9AglzLCcYoKHJB+wSD9DGbi3EkN9SegKu+MaLA85mxaskfwkw4 q1nwe1xDJTDyYgziU2VKC0F+uIJ3DE68seL3ELzcEJYciDcPwrIYoctjsSfMZV0RnraD Xkww== X-Gm-Message-State: AFqh2kqULIxvDWQzNOAN8RDkJIWMEf3VFPuv/GHD133pZWoUMnj9pYAq j5PrLBac6FXHo4XVCqsAAD9CqSwKgI3cBKG1OKwGxA== X-Google-Smtp-Source: AMrXdXsQ7w+8O+47UlcrH/eyB1AcY+iw3zi67xHAp19yIp7KZoxSU3hceHOEF+dEFVjlYfKxx8GN7IxiiG1wtM0JlDA= X-Received: by 2002:a05:6402:1654:b0:47f:e663:1d78 with SMTP id s20-20020a056402165400b0047fe6631d78mr1566473edx.237.1672302162986; Thu, 29 Dec 2022 00:22:42 -0800 (PST) MIME-Version: 1.0 References: <20220915164826.1396245-1-sarthakkukreti@google.com> <20220915164826.1396245-3-sarthakkukreti@google.com> In-Reply-To: From: Sarthak Kukreti Date: Thu, 29 Dec 2022 00:22:32 -0800 Message-ID: Subject: Re: [PATCH RFC 2/8] dm: Add support for block provisioning To: Mike Snitzer Cc: dm-devel@redhat.com, linux-block@vger.kernel.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Jens Axboe , "Michael S . Tsirkin" , Jason Wang , Paolo Bonzini , Stefan Hajnoczi , Alasdair Kergon , Mike Snitzer , "Theodore Ts'o" , Andreas Dilger , Bart Van Assche , Daniil Lunev , Evan Green , Gwendal Grignou Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 23, 2022 at 7:23 AM Mike Snitzer wrote: > > On Thu, Sep 15 2022 at 12:48P -0400, > Sarthak Kukreti wrote: > > > From: Sarthak Kukreti > > > > Add support to dm devices for REQ_OP_PROVISION. The default mode > > is to pass through the request and dm-thin will utilize it to provision > > blocks. > > > > Signed-off-by: Sarthak Kukreti > > --- > > drivers/md/dm-crypt.c | 4 +- > > drivers/md/dm-linear.c | 1 + > > drivers/md/dm-table.c | 17 +++++++ > > drivers/md/dm-thin.c | 86 +++++++++++++++++++++++++++++++++-- > > drivers/md/dm.c | 4 ++ > > include/linux/device-mapper.h | 6 +++ > > 6 files changed, 113 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > > index 159c6806c19b..357f0899cfb6 100644 > > --- a/drivers/md/dm-crypt.c > > +++ b/drivers/md/dm-crypt.c > > @@ -3081,6 +3081,8 @@ static int crypt_ctr_optional(struct dm_target *ti, unsigned int argc, char **ar > > if (ret) > > return ret; > > > > + ti->num_provision_bios = 1; > > + > > while (opt_params--) { > > opt_string = dm_shift_arg(&as); > > if (!opt_string) { > > @@ -3384,7 +3386,7 @@ static int crypt_map(struct dm_target *ti, struct bio *bio) > > * - for REQ_OP_DISCARD caller must use flush if IO ordering matters > > */ > > if (unlikely(bio->bi_opf & REQ_PREFLUSH || > > - bio_op(bio) == REQ_OP_DISCARD)) { > > + bio_op(bio) == REQ_OP_DISCARD || bio_op(bio) == REQ_OP_PROVISION)) { > > bio_set_dev(bio, cc->dev->bdev); > > if (bio_sectors(bio)) > > bio->bi_iter.bi_sector = cc->start + > > diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c > > index 3212ef6aa81b..1aa782149428 100644 > > --- a/drivers/md/dm-linear.c > > +++ b/drivers/md/dm-linear.c > > @@ -61,6 +61,7 @@ static int linear_ctr(struct dm_target *ti, unsigned int argc, char **argv) > > ti->num_discard_bios = 1; > > ti->num_secure_erase_bios = 1; > > ti->num_write_zeroes_bios = 1; > > + ti->num_provision_bios = 1; > > ti->private = lc; > > return 0; > > > > diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c > > index 332f96b58252..b7f9cb66b7ba 100644 > > --- a/drivers/md/dm-table.c > > +++ b/drivers/md/dm-table.c > > @@ -1853,6 +1853,18 @@ static bool dm_table_supports_write_zeroes(struct dm_table *t) > > return true; > > } > > > > +static bool dm_table_supports_provision(struct dm_table *t) > > +{ > > + for (unsigned int i = 0; i < t->num_targets; i++) { > > + struct dm_target *ti = dm_table_get_target(t, i); > > + > > + if (ti->num_provision_bios) > > + return true; > > + } > > + > > + return false; > > +} > > + > > This needs to go a step further and verify a device in the stack > actually services REQ_OP_PROVISION. > > Please see dm_table_supports_discards(): it iterates all devices in > the table and checks that support is advertised. > > For discard, DM requires that _all_ devices in a table advertise > support (that is pretty strict and likely could be relaxed to _any_). > > You'll need ti->provision_supported (like ->discards_supported) to > advertise actual support is provided by dm-thinp (even if underlying > devices don't support it). > > And yeah, dm-thinp passdown support for REQ_OP_PROVISION can follow > later as needed (if there actual HW that would benefit from > REQ_OP_PROVISION). > Done, thanks (the provision support, not the passdown)! I think the one case where passdown might help is to build images with dm-thinp already set up on one of the partitions (I have something in the works for ChromiumOS images to do VM tests with preset state :)). That would allow us to preallocate space for thin logical volumes inside the image file. > Mike >