Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2630767rwd; Mon, 15 May 2023 14:38:47 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7yVJuVKFSmTtAi8mu65dopTXygcesEbqh2+XcBZD9l/bz9DxbNqxD/Yj8kTgnJOcqEFq1o X-Received: by 2002:a17:90a:734b:b0:24e:5a5a:1050 with SMTP id j11-20020a17090a734b00b0024e5a5a1050mr36390789pjs.24.1684186727079; Mon, 15 May 2023 14:38:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684186727; cv=none; d=google.com; s=arc-20160816; b=fdGxsLZ27vla4QFbhaDG0FM/2UcIxW072oZKtfiJfzFS1NawwaSuvv4vByR3cekoJJ 3whVqP8XvMRPe3OJc07QsT+p/aKQZYFzd0gpa37lmttpk5A2DI0h09nD1/TeSfO7epzd wSX4vQ/34rYfjw2gzgucEyjQcSpctZ4FY3ZQy1DhRQmwH8Lx7TF4G7/fR2qQWJTpMWpM lImMtOfLci0XRhFu+ULrGXwGkqFJw+yFfMC/H0S6OpBrqW5Rjw6qPsWIpTynraszZw/E d769e47mcIq9DMtht/L/1dnVvSp2n0UqIAAt3LXkU/G71e+22glZUXCm6g+3X2qFLbvT I57A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=0+97QIKHZALmFiK8g1VXhuSr7RLu+60+zvsYBuHgbGg=; b=HNi14ee3luPGpVT/5LUlVUkgml2125Bmqf97d8wOgOxWUa3TzpxbXOYubugPi6fKGT J0zLeokh8COxAoUbF1T1YvdrykT4s5OAAclKCXwPuRz5CL2UbyVXwLjtKG1LT6F3zhf5 yrYDkCR35ZWZlage5i7TD25TjI7fElLMf2qE/fRgktXvatSb0iv3Qrb6uWG4KuJ9QOJh sN63C3+w4f2m9QLv9H/eE4beq6V2qwI/h8GP392kJ1Hu7iBq7q6yBJ1uIctPnvUJIBBg xfvk9+BScOoLm81p/zAvnqlj+eA8B70FeAN58tsKB0XCg3QUEt716ce9C7KIxnDuNlxZ /vnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=RJ43ZLZa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v71-20020a63894a000000b00514329f7ebdsi16465071pgd.344.2023.05.15.14.38.32; Mon, 15 May 2023 14:38:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=RJ43ZLZa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244832AbjEOVb5 (ORCPT + 99 others); Mon, 15 May 2023 17:31:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245466AbjEOVbz (ORCPT ); Mon, 15 May 2023 17:31:55 -0400 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAA7CE73A for ; Mon, 15 May 2023 14:31:52 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-50c8d87c775so18485935a12.3 for ; Mon, 15 May 2023 14:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1684186311; x=1686778311; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0+97QIKHZALmFiK8g1VXhuSr7RLu+60+zvsYBuHgbGg=; b=RJ43ZLZaLLvaXaU48DAqFaUazi1XdW+GzxWfHJT5XeDgDpzKHeu5MNWZny6MxbA0OA oPe6ekVWSZF8FhY1pcd7Q9kmUBnfHNdPl772Rvmn/QhYD4qom8AgDkG5qtlBg2wx9KCf JWeHWlZSGtpQ2QpjfAEvfhPCxAhtSoUUURhOM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684186311; x=1686778311; h=content-transfer-encoding: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=0+97QIKHZALmFiK8g1VXhuSr7RLu+60+zvsYBuHgbGg=; b=BYt3H0ypBHdXdoTBHdJ6wE2jjc7+TWIyZjgVEmKJd/ecn1CxKYcvJ9KG1vPa/9nAkV XYgK0PUj+Oyvr0QG9YZ0hKYxfkS25nPjTlDz9p1B8ygMZxkVUIX7Z+eRi68bnX1wi5Ky ht80SRWYnWX1odBsyDRTmmWwnOIJZXpdYAGWiseZVbkTbOHSrQragUTNvl7Ov4XRNdmA vHRc8oc8uW7+1z6+3XobZtcxeTfVbypWttXXczNcIYyVbVzjwh0WK/0W37V4UYDLncEX erRCcwPtBNnU7uo9NxfVYn4ylRSdWSmQdsjASRjohfC6heHdRfnkyJ+UmMEmOZHuH9Q6 46Pw== X-Gm-Message-State: AC+VfDz+asb2/RH5Fp6MwL10795D6jHbyzJcRPe6HB3dSEfRCFK1ux6e wzwtWNWVvSGWcIpe8LtWYQG1dfphLKqX3hxHXiyUTA== X-Received: by 2002:a17:907:728e:b0:96a:e7cc:b8b1 with SMTP id dt14-20020a170907728e00b0096ae7ccb8b1mr8614530ejc.56.1684186311425; Mon, 15 May 2023 14:31:51 -0700 (PDT) MIME-Version: 1.0 References: <20230420004850.297045-1-sarthakkukreti@chromium.org> <20230506062909.74601-1-sarthakkukreti@chromium.org> <20230506062909.74601-6-sarthakkukreti@chromium.org> In-Reply-To: From: Sarthak Kukreti Date: Mon, 15 May 2023 14:31:40 -0700 Message-ID: Subject: Re: [PATCH v6 5/5] loop: Add support for provision requests To: Brian Foster Cc: dm-devel@redhat.com, linux-block@vger.kernel.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jens Axboe , "Michael S. Tsirkin" , Jason Wang , Stefan Hajnoczi , Alasdair Kergon , Mike Snitzer , Christoph Hellwig , "Theodore Ts'o" , Andreas Dilger , Bart Van Assche , "Darrick J. Wong" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 15, 2023 at 5:37=E2=80=AFAM Brian Foster w= rote: > > On Fri, May 05, 2023 at 11:29:09PM -0700, Sarthak Kukreti wrote: > > Add support for provision requests to loopback devices. > > Loop devices will configure provision support based on > > whether the underlying block device/file can support > > the provision request and upon receiving a provision bio, > > will map it to the backing device/storage. For loop devices > > over files, a REQ_OP_PROVISION request will translate to > > an fallocate mode 0 call on the backing file. > > > > Signed-off-by: Sarthak Kukreti > > --- > > drivers/block/loop.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > > > diff --git a/drivers/block/loop.c b/drivers/block/loop.c > > index bc31bb7072a2..13c4b4f8b9c1 100644 > > --- a/drivers/block/loop.c > > +++ b/drivers/block/loop.c > > @@ -327,6 +327,24 @@ static int lo_fallocate(struct loop_device *lo, st= ruct request *rq, loff_t pos, > > return ret; > > } > > > > +static int lo_req_provision(struct loop_device *lo, struct request *rq= , loff_t pos) > > +{ > > + struct file *file =3D lo->lo_backing_file; > > + struct request_queue *q =3D lo->lo_queue; > > + int ret; > > + > > + if (!q->limits.max_provision_sectors) { > > + ret =3D -EOPNOTSUPP; > > + goto out; > > + } > > + > > + ret =3D file->f_op->fallocate(file, 0, pos, blk_rq_bytes(rq)); > > + if (unlikely(ret && ret !=3D -EINVAL && ret !=3D -EOPNOTSUPP)) > > + ret =3D -EIO; > > + out: > > + return ret; > > +} > > + > > static int lo_req_flush(struct loop_device *lo, struct request *rq) > > { > > int ret =3D vfs_fsync(lo->lo_backing_file, 0); > > @@ -488,6 +506,8 @@ static int do_req_filebacked(struct loop_device *lo= , struct request *rq) > > FALLOC_FL_PUNCH_HOLE); > > case REQ_OP_DISCARD: > > return lo_fallocate(lo, rq, pos, FALLOC_FL_PUNCH_HOLE); > > + case REQ_OP_PROVISION: > > + return lo_req_provision(lo, rq, pos); > > Hi Sarthak, > > The only thing that stands out to me is the separate lo_req_provision() > helper here. It seems it might be a little cleaner to extend and reuse > lo_req_fallocate()..? But that's not something I feel strongly about, so > this all looks pretty good to me either way, FWIW. > Fair point, I think that should shorten the patch (and for correctness, we'd want to add FALLOC_FL_KEEP_SIZE for REQ_OP_PROVISION too). I'll fix this up in v7. Best Sarthak > Brian > > > case REQ_OP_WRITE: > > if (cmd->use_aio) > > return lo_rw_aio(lo, cmd, pos, ITER_SOURCE); > > @@ -754,6 +774,25 @@ static void loop_sysfs_exit(struct loop_device *lo= ) > > &loop_attribute_group); > > } > > > > +static void loop_config_provision(struct loop_device *lo) > > +{ > > + struct file *file =3D lo->lo_backing_file; > > + struct inode *inode =3D file->f_mapping->host; > > + > > + /* > > + * If the backing device is a block device, mirror its provisioni= ng > > + * capability. > > + */ > > + if (S_ISBLK(inode->i_mode)) { > > + blk_queue_max_provision_sectors(lo->lo_queue, > > + bdev_max_provision_sectors(I_BDEV(inode))); > > + } else if (file->f_op->fallocate) { > > + blk_queue_max_provision_sectors(lo->lo_queue, UINT_MAX >>= 9); > > + } else { > > + blk_queue_max_provision_sectors(lo->lo_queue, 0); > > + } > > +} > > + > > static void loop_config_discard(struct loop_device *lo) > > { > > struct file *file =3D lo->lo_backing_file; > > @@ -1092,6 +1131,7 @@ static int loop_configure(struct loop_device *lo,= fmode_t mode, > > blk_queue_io_min(lo->lo_queue, bsize); > > > > loop_config_discard(lo); > > + loop_config_provision(lo); > > loop_update_rotational(lo); > > loop_update_dio(lo); > > loop_sysfs_init(lo); > > @@ -1304,6 +1344,7 @@ loop_set_status(struct loop_device *lo, const str= uct loop_info64 *info) > > } > > > > loop_config_discard(lo); > > + loop_config_provision(lo); > > > > /* update dio if lo_offset or transfer is changed */ > > __loop_update_dio(lo, lo->use_dio); > > @@ -1830,6 +1871,7 @@ static blk_status_t loop_queue_rq(struct blk_mq_h= w_ctx *hctx, > > case REQ_OP_FLUSH: > > case REQ_OP_DISCARD: > > case REQ_OP_WRITE_ZEROES: > > + case REQ_OP_PROVISION: > > cmd->use_aio =3D false; > > break; > > default: > > -- > > 2.40.1.521.gf1e218fcd8-goog > > >