From: Brian Foster <bfoster@redhat.com>
To: Sarthak Kukreti <sarthakkukreti@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@infradead.org>,
Theodore Ts'o <tytso@mit.edu>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Jason Wang <jasowang@redhat.com>,
Bart Van Assche <bvanassche@google.com>,
Mike Snitzer <snitzer@kernel.org>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
dm-devel@redhat.com, Andreas Dilger <adilger.kernel@dilger.ca>,
Stefan Hajnoczi <stefanha@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [dm-devel] [PATCH v6 5/5] loop: Add support for provision requests
Date: Mon, 15 May 2023 08:40:10 -0400 [thread overview]
Message-ID: <ZGIoKi7d5bKcMWw4@bfoster> (raw)
In-Reply-To: <20230506062909.74601-6-sarthakkukreti@chromium.org>
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 <sarthakkukreti@chromium.org>
> ---
> 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, struct 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 = lo->lo_backing_file;
> + struct request_queue *q = lo->lo_queue;
> + int ret;
> +
> + if (!q->limits.max_provision_sectors) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> +
> + ret = file->f_op->fallocate(file, 0, pos, blk_rq_bytes(rq));
> + if (unlikely(ret && ret != -EINVAL && ret != -EOPNOTSUPP))
> + ret = -EIO;
> + out:
> + return ret;
> +}
> +
> static int lo_req_flush(struct loop_device *lo, struct request *rq)
> {
> int ret = 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.
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 = lo->lo_backing_file;
> + struct inode *inode = file->f_mapping->host;
> +
> + /*
> + * If the backing device is a block device, mirror its provisioning
> + * 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 = 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 struct 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_hw_ctx *hctx,
> case REQ_OP_FLUSH:
> case REQ_OP_DISCARD:
> case REQ_OP_WRITE_ZEROES:
> + case REQ_OP_PROVISION:
> cmd->use_aio = false;
> break;
> default:
> --
> 2.40.1.521.gf1e218fcd8-goog
>
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Brian Foster <bfoster@redhat.com>
To: Sarthak Kukreti <sarthakkukreti@chromium.org>
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 <axboe@kernel.dk>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Bart Van Assche <bvanassche@google.com>,
"Darrick J. Wong" <djwong@kernel.org>
Subject: Re: [PATCH v6 5/5] loop: Add support for provision requests
Date: Mon, 15 May 2023 08:40:10 -0400 [thread overview]
Message-ID: <ZGIoKi7d5bKcMWw4@bfoster> (raw)
In-Reply-To: <20230506062909.74601-6-sarthakkukreti@chromium.org>
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 <sarthakkukreti@chromium.org>
> ---
> 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, struct 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 = lo->lo_backing_file;
> + struct request_queue *q = lo->lo_queue;
> + int ret;
> +
> + if (!q->limits.max_provision_sectors) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> +
> + ret = file->f_op->fallocate(file, 0, pos, blk_rq_bytes(rq));
> + if (unlikely(ret && ret != -EINVAL && ret != -EOPNOTSUPP))
> + ret = -EIO;
> + out:
> + return ret;
> +}
> +
> static int lo_req_flush(struct loop_device *lo, struct request *rq)
> {
> int ret = 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.
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 = lo->lo_backing_file;
> + struct inode *inode = file->f_mapping->host;
> +
> + /*
> + * If the backing device is a block device, mirror its provisioning
> + * 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 = 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 struct 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_hw_ctx *hctx,
> case REQ_OP_FLUSH:
> case REQ_OP_DISCARD:
> case REQ_OP_WRITE_ZEROES:
> + case REQ_OP_PROVISION:
> cmd->use_aio = false;
> break;
> default:
> --
> 2.40.1.521.gf1e218fcd8-goog
>
next prev parent reply other threads:[~2023-05-15 12:37 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20221229071647.437095-1-sarthakkukreti@chromium.org>
2023-04-14 0:02 ` [dm-devel] [PATCH v3 0/3] Introduce provisioning primitives for thinly provisioned storage Sarthak Kukreti
2023-04-14 0:02 ` Sarthak Kukreti
2023-04-14 0:02 ` [dm-devel] [PATCH v3 1/3] block: Introduce provisioning primitives Sarthak Kukreti
2023-04-14 0:02 ` Sarthak Kukreti
2023-04-17 17:35 ` [dm-devel] " Brian Foster
2023-04-17 17:35 ` Brian Foster
2023-04-18 22:13 ` [dm-devel] " Sarthak Kukreti
2023-04-18 22:13 ` Sarthak Kukreti
2023-04-14 0:02 ` [dm-devel] [PATCH v3 2/3] dm: Add support for block provisioning Sarthak Kukreti
2023-04-14 0:02 ` Sarthak Kukreti
2023-04-14 13:32 ` [dm-devel] " Joe Thornber
2023-04-14 18:14 ` Mike Snitzer
2023-04-14 18:14 ` Mike Snitzer
2023-04-14 21:58 ` [dm-devel] " Mike Snitzer
2023-04-14 21:58 ` Mike Snitzer
2023-04-18 22:13 ` [dm-devel] " Sarthak Kukreti
2023-04-18 22:13 ` Sarthak Kukreti
2023-04-14 0:02 ` [dm-devel] [PATCH v3 3/3] loop: Add support for provision requests Sarthak Kukreti
2023-04-14 0:02 ` Sarthak Kukreti
2023-04-18 22:12 ` [dm-devel] [PATCH v4 0/4] Introduce provisioning primitives for thinly provisioned storage Sarthak Kukreti
2023-04-18 22:12 ` Sarthak Kukreti
2023-04-18 22:12 ` [dm-devel] [PATCH v4 1/4] block: Introduce provisioning primitives Sarthak Kukreti
2023-04-18 22:12 ` Sarthak Kukreti
2023-04-18 22:43 ` [dm-devel] " Bart Van Assche
2023-04-18 22:43 ` Bart Van Assche
2023-04-20 17:41 ` [dm-devel] " Sarthak Kukreti
2023-04-20 17:41 ` Sarthak Kukreti
2023-04-19 15:36 ` [dm-devel] " Darrick J. Wong
2023-04-19 15:36 ` Darrick J. Wong
2023-04-19 16:17 ` Mike Snitzer
2023-04-19 16:17 ` Mike Snitzer
2023-04-19 17:26 ` [dm-devel] " Darrick J. Wong
2023-04-19 17:26 ` Darrick J. Wong
2023-04-19 23:21 ` [dm-devel] " Dave Chinner
2023-04-19 23:21 ` Dave Chinner
2023-04-20 0:53 ` [dm-devel] " Sarthak Kukreti
2023-04-20 0:53 ` Sarthak Kukreti
2023-04-18 22:12 ` [dm-devel] [PATCH v4 2/4] dm: Add block provisioning support Sarthak Kukreti
2023-04-18 22:12 ` Sarthak Kukreti
2023-04-18 22:12 ` [dm-devel] [PATCH v4 3/4] dm-thin: Add REQ_OP_PROVISION support Sarthak Kukreti
2023-04-18 22:12 ` Sarthak Kukreti
2023-04-18 22:12 ` [dm-devel] [PATCH v4 4/4] loop: Add support for provision requests Sarthak Kukreti
2023-04-18 22:12 ` Sarthak Kukreti
2023-04-20 0:48 ` [dm-devel] [PATCH v5 0/5] Introduce block provisioning primitives Sarthak Kukreti
2023-04-20 0:48 ` Sarthak Kukreti
2023-04-20 0:48 ` [dm-devel] [PATCH v5 1/5] block: Don't invalidate pagecache for invalid falloc modes Sarthak Kukreti
2023-04-20 0:48 ` Sarthak Kukreti
2023-04-20 1:22 ` [dm-devel] " Darrick J. Wong
2023-04-20 1:22 ` Darrick J. Wong
2023-04-20 1:48 ` [dm-devel] " Sarthak Kukreti
2023-04-20 1:48 ` Sarthak Kukreti
2023-04-20 1:47 ` [dm-devel] [PATCH v5-fix " Sarthak Kukreti
2023-04-20 1:47 ` Sarthak Kukreti
2023-04-20 16:20 ` [dm-devel] " Mike Snitzer
2023-04-20 16:20 ` Mike Snitzer
2023-04-20 17:28 ` [dm-devel] " Sarthak Kukreti
2023-04-20 17:28 ` Sarthak Kukreti
2023-04-20 18:17 ` [dm-devel] " Sarthak Kukreti
2023-04-20 18:17 ` Sarthak Kukreti
2023-04-20 18:15 ` [dm-devel] " Sarthak Kukreti
2023-04-20 18:15 ` Sarthak Kukreti
2023-04-24 15:54 ` [dm-devel] [PATCH v5 " kernel test robot
2023-04-24 15:54 ` kernel test robot
2023-05-04 8:50 ` [dm-devel] " kernel test robot
2023-05-04 8:50 ` kernel test robot
2023-04-20 0:48 ` [dm-devel] [PATCH v5 2/5] block: Introduce provisioning primitives Sarthak Kukreti
2023-04-20 0:48 ` Sarthak Kukreti
2023-04-20 0:48 ` [dm-devel] [PATCH v5 3/5] dm: Add block provisioning support Sarthak Kukreti
2023-04-20 0:48 ` Sarthak Kukreti
2023-04-20 0:48 ` [dm-devel] [PATCH v5 4/5] dm-thin: Add REQ_OP_PROVISION support Sarthak Kukreti
2023-04-20 0:48 ` Sarthak Kukreti
2023-05-01 19:15 ` [dm-devel] " Mike Snitzer
2023-05-01 19:15 ` Mike Snitzer
2023-05-06 6:32 ` [dm-devel] " Sarthak Kukreti
2023-05-06 6:32 ` Sarthak Kukreti
2023-04-20 0:48 ` [dm-devel] [PATCH v5 5/5] loop: Add support for provision requests Sarthak Kukreti
2023-04-20 0:48 ` Sarthak Kukreti
2023-05-06 6:29 ` [dm-devel] [PATCH v6 0/5] Introduce block provisioning primitives Sarthak Kukreti
2023-05-06 6:29 ` Sarthak Kukreti
2023-05-06 6:29 ` [dm-devel] [PATCH v6 1/5] block: Don't invalidate pagecache for invalid falloc modes Sarthak Kukreti
2023-05-06 6:29 ` Sarthak Kukreti
2023-05-09 16:51 ` [dm-devel] " Mike Snitzer
2023-05-09 16:51 ` Mike Snitzer
2023-05-12 18:31 ` [dm-devel] " Darrick J. Wong
2023-05-12 18:31 ` Darrick J. Wong
2023-05-06 6:29 ` [dm-devel] [PATCH v6 2/5] block: Introduce provisioning primitives Sarthak Kukreti
2023-05-06 6:29 ` Sarthak Kukreti
2023-05-09 16:52 ` [dm-devel] " Mike Snitzer
2023-05-09 16:52 ` Mike Snitzer
2023-05-12 18:37 ` [dm-devel] " Darrick J. Wong
2023-05-12 18:37 ` Darrick J. Wong
2023-05-15 21:55 ` [dm-devel] " Sarthak Kukreti
2023-05-15 21:55 ` Sarthak Kukreti
2023-05-06 6:29 ` [dm-devel] [PATCH v6 3/5] dm: Add block provisioning support Sarthak Kukreti
2023-05-06 6:29 ` Sarthak Kukreti
2023-05-09 16:52 ` [dm-devel] " Mike Snitzer
2023-05-09 16:52 ` Mike Snitzer
2023-05-06 6:29 ` [dm-devel] [PATCH v6 4/5] dm-thin: Add REQ_OP_PROVISION support Sarthak Kukreti
2023-05-06 6:29 ` Sarthak Kukreti
2023-05-09 16:58 ` [dm-devel] " Mike Snitzer
2023-05-09 16:58 ` Mike Snitzer
2023-05-11 20:03 ` [dm-devel] " Sarthak Kukreti
2023-05-11 20:03 ` Sarthak Kukreti
2023-05-12 14:34 ` [dm-devel] " Mike Snitzer
2023-05-12 14:34 ` Mike Snitzer
2023-05-12 17:32 ` [dm-devel] " Mike Snitzer
2023-05-12 17:32 ` Mike Snitzer
2023-05-15 21:19 ` [dm-devel] " Sarthak Kukreti
2023-05-15 21:19 ` Sarthak Kukreti
2023-05-06 6:29 ` [dm-devel] [PATCH v6 5/5] loop: Add support for provision requests Sarthak Kukreti
2023-05-06 6:29 ` Sarthak Kukreti
2023-05-15 12:40 ` Brian Foster [this message]
2023-05-15 12:40 ` Brian Foster
2023-05-15 21:31 ` [dm-devel] " Sarthak Kukreti
2023-05-15 21:31 ` Sarthak Kukreti
2023-05-12 18:28 ` [dm-devel] [PATCH v6 0/5] Introduce block provisioning primitives Darrick J. Wong
2023-05-12 18:28 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZGIoKi7d5bKcMWw4@bfoster \
--to=bfoster@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@google.com \
--cc=djwong@kernel.org \
--cc=dm-devel@redhat.com \
--cc=hch@infradead.org \
--cc=jasowang@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=sarthakkukreti@chromium.org \
--cc=snitzer@kernel.org \
--cc=stefanha@redhat.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.