From: Mike Snitzer <snitzer@redhat.com>
To: Sarthak Kukreti <sarthakkukreti@chromium.org>,
Joe Thornber <ejt@redhat.com>, Brian Foster <bfoster@redhat.com>
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>,
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 v7 4/5] dm-thin: Add REQ_OP_PROVISION support
Date: Thu, 8 Jun 2023 20:28:16 -0400 [thread overview]
Message-ID: <ZIJyIOIPx+jE9/iv@redhat.com> (raw)
In-Reply-To: <ZIJHH+ekx59+6Uu0@redhat.com>
On Thu, Jun 08 2023 at 5:24P -0400,
Mike Snitzer <snitzer@kernel.org> wrote:
> On Fri, May 19 2023 at 11:23P -0400,
> Mike Snitzer <snitzer@kernel.org> wrote:
>
> > On Thu, May 18 2023 at 6:33P -0400,
> > Sarthak Kukreti <sarthakkukreti@chromium.org> wrote:
> >
> > > dm-thinpool uses the provision request to provision
> > > blocks for a dm-thin device. dm-thinpool currently does not
> > > pass through REQ_OP_PROVISION to underlying devices.
> > >
> > > For shared blocks, provision requests will break sharing and copy the
> > > contents of the entire block. Additionally, if 'skip_block_zeroing'
> > > is not set, dm-thin will opt to zero out the entire range as a part
> > > of provisioning.
> > >
> > > Signed-off-by: Sarthak Kukreti <sarthakkukreti@chromium.org>
> > > ---
> > > drivers/md/dm-thin.c | 74 +++++++++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 70 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
> > > index 2b13c949bd72..f1b68b558cf0 100644
> > > --- a/drivers/md/dm-thin.c
> > > +++ b/drivers/md/dm-thin.c
> > > @@ -1245,8 +1247,8 @@ static int io_overlaps_block(struct pool *pool, struct bio *bio)
> > >
> > > static int io_overwrites_block(struct pool *pool, struct bio *bio)
> > > {
> > > - return (bio_data_dir(bio) == WRITE) &&
> > > - io_overlaps_block(pool, bio);
> > > + return (bio_data_dir(bio) == WRITE) && io_overlaps_block(pool, bio) &&
> > > + bio_op(bio) != REQ_OP_PROVISION;
> > > }
> > >
> > > static void save_and_set_endio(struct bio *bio, bio_end_io_t **save,
> > > @@ -1394,6 +1396,9 @@ static void schedule_zero(struct thin_c *tc, dm_block_t virt_block,
> > > m->data_block = data_block;
> > > m->cell = cell;
> > >
> > > + if (bio && bio_op(bio) == REQ_OP_PROVISION)
> > > + m->bio = bio;
> > > +
> > > /*
> > > * If the whole block of data is being overwritten or we are not
> > > * zeroing pre-existing data, we can issue the bio immediately.
> >
> > This doesn't seem like the best way to address avoiding passdown of
> > provision bios (relying on process_prepared_mapping's implementation
> > that happens to do the right thing if m->bio set). Doing so cascades
> > into relying on complete_overwrite_bio() happening to _not_ actually
> > being specific to "overwrite" bios.
> >
> > I don't have a better suggestion yet but will look closer. Just think
> > this needs to be formalized a bit more rather than it happening to
> > "just work".
> >
> > Cc'ing Joe to see what he thinks too. This is something we can clean
> > up with a follow-on patch though, so not a show-stopper for this
> > series.
>
> I haven't circled back to look close enough at this but
> REQ_OP_PROVISION bios _are_ being passed down to the thin-pool's
> underlying data device.
>
> Brian Foster reported that if he issues a REQ_OP_PROVISION to a thin
> device after a snapshot (to break sharing), it'll fail with
> -EOPNOTSUPP (response is from bio being passed down to device that
> doesn't support it). I was able to reproduce with:
>
> # fallocate --offset 0 --length 1048576 /dev/test/thin
> # lvcreate -n snap --snapshot test/thin
>
> # fallocate --offset 0 --length 1048576 /dev/test/thin
> fallocate: fallocate failed: Operation not supported
>
> But reports success when retried:
> # fallocate --offset 0 --length 1048576 /dev/test/thin
> # echo $?
> 0
>
> It's somewhat moot in that Joe will be reimplementing handling for
> REQ_OP_PROVISION _but_ in the meantime it'd be nice to have a version
> of this patch that doesn't error (due to passdown of REQ_OP_PROVISION)
> when breaking sharing. Primarily so the XFS guys (Dave and Brian) can
> make progress.
>
> I'll take a closer look tomorrow but figured I'd let you know.
This fixes the issue for me (causes process_prepared_mapping to end
the bio without REQ_OP_PROVISION passdown).
But like I said above back on May 19: needs cleanup to make it less of
a hack for the REQ_OP_PROVISION case. At a minimum
complete_overwrite_bio() would need renaming.
diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 43a6702f9efe..434a3b37af2f 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -1324,6 +1324,9 @@ static void schedule_copy(struct thin_c *tc, dm_block_t virt_block,
m->data_block = data_dest;
m->cell = cell;
+ if (bio_op(bio) == REQ_OP_PROVISION)
+ m->bio = bio;
+
/*
* quiesce action + copy action + an extra reference held for the
* duration of this function (we may need to inc later for a
--
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: Mike Snitzer <snitzer@redhat.com>
To: Sarthak Kukreti <sarthakkukreti@chromium.org>,
Joe Thornber <ejt@redhat.com>, Brian Foster <bfoster@redhat.com>
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>,
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>,
Christoph Hellwig <hch@infradead.org>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Stefan Hajnoczi <stefanha@redhat.com>,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH v7 4/5] dm-thin: Add REQ_OP_PROVISION support
Date: Thu, 8 Jun 2023 20:28:16 -0400 [thread overview]
Message-ID: <ZIJyIOIPx+jE9/iv@redhat.com> (raw)
In-Reply-To: <ZIJHH+ekx59+6Uu0@redhat.com>
On Thu, Jun 08 2023 at 5:24P -0400,
Mike Snitzer <snitzer@kernel.org> wrote:
> On Fri, May 19 2023 at 11:23P -0400,
> Mike Snitzer <snitzer@kernel.org> wrote:
>
> > On Thu, May 18 2023 at 6:33P -0400,
> > Sarthak Kukreti <sarthakkukreti@chromium.org> wrote:
> >
> > > dm-thinpool uses the provision request to provision
> > > blocks for a dm-thin device. dm-thinpool currently does not
> > > pass through REQ_OP_PROVISION to underlying devices.
> > >
> > > For shared blocks, provision requests will break sharing and copy the
> > > contents of the entire block. Additionally, if 'skip_block_zeroing'
> > > is not set, dm-thin will opt to zero out the entire range as a part
> > > of provisioning.
> > >
> > > Signed-off-by: Sarthak Kukreti <sarthakkukreti@chromium.org>
> > > ---
> > > drivers/md/dm-thin.c | 74 +++++++++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 70 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
> > > index 2b13c949bd72..f1b68b558cf0 100644
> > > --- a/drivers/md/dm-thin.c
> > > +++ b/drivers/md/dm-thin.c
> > > @@ -1245,8 +1247,8 @@ static int io_overlaps_block(struct pool *pool, struct bio *bio)
> > >
> > > static int io_overwrites_block(struct pool *pool, struct bio *bio)
> > > {
> > > - return (bio_data_dir(bio) == WRITE) &&
> > > - io_overlaps_block(pool, bio);
> > > + return (bio_data_dir(bio) == WRITE) && io_overlaps_block(pool, bio) &&
> > > + bio_op(bio) != REQ_OP_PROVISION;
> > > }
> > >
> > > static void save_and_set_endio(struct bio *bio, bio_end_io_t **save,
> > > @@ -1394,6 +1396,9 @@ static void schedule_zero(struct thin_c *tc, dm_block_t virt_block,
> > > m->data_block = data_block;
> > > m->cell = cell;
> > >
> > > + if (bio && bio_op(bio) == REQ_OP_PROVISION)
> > > + m->bio = bio;
> > > +
> > > /*
> > > * If the whole block of data is being overwritten or we are not
> > > * zeroing pre-existing data, we can issue the bio immediately.
> >
> > This doesn't seem like the best way to address avoiding passdown of
> > provision bios (relying on process_prepared_mapping's implementation
> > that happens to do the right thing if m->bio set). Doing so cascades
> > into relying on complete_overwrite_bio() happening to _not_ actually
> > being specific to "overwrite" bios.
> >
> > I don't have a better suggestion yet but will look closer. Just think
> > this needs to be formalized a bit more rather than it happening to
> > "just work".
> >
> > Cc'ing Joe to see what he thinks too. This is something we can clean
> > up with a follow-on patch though, so not a show-stopper for this
> > series.
>
> I haven't circled back to look close enough at this but
> REQ_OP_PROVISION bios _are_ being passed down to the thin-pool's
> underlying data device.
>
> Brian Foster reported that if he issues a REQ_OP_PROVISION to a thin
> device after a snapshot (to break sharing), it'll fail with
> -EOPNOTSUPP (response is from bio being passed down to device that
> doesn't support it). I was able to reproduce with:
>
> # fallocate --offset 0 --length 1048576 /dev/test/thin
> # lvcreate -n snap --snapshot test/thin
>
> # fallocate --offset 0 --length 1048576 /dev/test/thin
> fallocate: fallocate failed: Operation not supported
>
> But reports success when retried:
> # fallocate --offset 0 --length 1048576 /dev/test/thin
> # echo $?
> 0
>
> It's somewhat moot in that Joe will be reimplementing handling for
> REQ_OP_PROVISION _but_ in the meantime it'd be nice to have a version
> of this patch that doesn't error (due to passdown of REQ_OP_PROVISION)
> when breaking sharing. Primarily so the XFS guys (Dave and Brian) can
> make progress.
>
> I'll take a closer look tomorrow but figured I'd let you know.
This fixes the issue for me (causes process_prepared_mapping to end
the bio without REQ_OP_PROVISION passdown).
But like I said above back on May 19: needs cleanup to make it less of
a hack for the REQ_OP_PROVISION case. At a minimum
complete_overwrite_bio() would need renaming.
diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 43a6702f9efe..434a3b37af2f 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -1324,6 +1324,9 @@ static void schedule_copy(struct thin_c *tc, dm_block_t virt_block,
m->data_block = data_dest;
m->cell = cell;
+ if (bio_op(bio) == REQ_OP_PROVISION)
+ m->bio = bio;
+
/*
* quiesce action + copy action + an extra reference held for the
* duration of this function (we may need to inc later for a
next prev parent reply other threads:[~2023-06-09 0:28 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 22:33 [dm-devel] [PATCH v7 0/5] Introduce provisioning primitives Sarthak Kukreti
2023-05-18 22:33 ` Sarthak Kukreti
2023-05-18 22:33 ` [dm-devel] [PATCH v7 1/5] block: Don't invalidate pagecache for invalid falloc modes Sarthak Kukreti
2023-05-18 22:33 ` Sarthak Kukreti
2023-05-19 4:09 ` [dm-devel] " Christoph Hellwig
2023-05-19 4:09 ` Christoph Hellwig
2023-05-19 15:17 ` [dm-devel] " Darrick J. Wong
2023-05-19 15:17 ` Darrick J. Wong
2023-05-18 22:33 ` [dm-devel] [PATCH v7 2/5] block: Introduce provisioning primitives Sarthak Kukreti
2023-05-18 22:33 ` Sarthak Kukreti
2023-05-19 4:18 ` [dm-devel] " Christoph Hellwig
2023-05-19 4:18 ` Christoph Hellwig
2023-06-09 20:00 ` [dm-devel] " Mike Snitzer
2023-06-09 20:00 ` Mike Snitzer
2023-05-18 22:33 ` [dm-devel] [PATCH v7 3/5] dm: Add block provisioning support Sarthak Kukreti
2023-05-18 22:33 ` Sarthak Kukreti
2023-05-18 22:33 ` [dm-devel] [PATCH v7 4/5] dm-thin: Add REQ_OP_PROVISION support Sarthak Kukreti
2023-05-18 22:33 ` Sarthak Kukreti
2023-05-19 15:23 ` [dm-devel] " Mike Snitzer
2023-05-19 15:23 ` Mike Snitzer
2023-06-08 21:24 ` [dm-devel] " Mike Snitzer
2023-06-08 21:24 ` Mike Snitzer
2023-06-09 0:28 ` Mike Snitzer [this message]
2023-06-09 0:28 ` Mike Snitzer
2023-05-18 22:33 ` [dm-devel] [PATCH v7 5/5] loop: Add support for provision requests Sarthak Kukreti
2023-05-18 22:33 ` Sarthak Kukreti
2023-05-22 16:37 ` [dm-devel] " Darrick J. Wong
2023-05-22 16:37 ` Darrick J. Wong
2023-05-22 22:09 ` Sarthak Kukreti
2023-05-22 22:09 ` Sarthak Kukreti
2023-05-23 1:22 ` [dm-devel] " Darrick J. Wong
2023-05-23 1:22 ` Darrick J. Wong
2023-10-07 1:29 ` [dm-devel] " Sarthak Kukreti
2023-10-07 1:29 ` Sarthak Kukreti
2023-05-19 4:09 ` [dm-devel] [PATCH v7 0/5] Introduce provisioning primitives Christoph Hellwig
2023-05-19 4:09 ` Christoph Hellwig
2023-05-19 14:41 ` [dm-devel] " Mike Snitzer
2023-05-19 14:41 ` Mike Snitzer
2023-05-19 23:07 ` [dm-devel] " Dave Chinner
2023-05-19 23:07 ` Dave Chinner
2023-05-22 18:27 ` [dm-devel] " Mike Snitzer
2023-05-22 18:27 ` Mike Snitzer
2023-05-23 14:05 ` [dm-devel] " Brian Foster
2023-05-23 14:05 ` Brian Foster
2023-05-23 15:26 ` [dm-devel] " Mike Snitzer
2023-05-23 15:26 ` Mike Snitzer
2023-05-24 0:40 ` [dm-devel] " Dave Chinner
2023-05-24 0:40 ` Dave Chinner
2023-05-24 20:02 ` [dm-devel] " Mike Snitzer
2023-05-24 20:02 ` Mike Snitzer
2023-05-25 11:39 ` [dm-devel] " Dave Chinner
2023-05-25 11:39 ` Dave Chinner
2023-05-25 16:00 ` [dm-devel] " Mike Snitzer
2023-05-25 16:00 ` Mike Snitzer
2023-05-25 22:47 ` [dm-devel] " Sarthak Kukreti
2023-05-25 22:47 ` Sarthak Kukreti
2023-05-26 1:36 ` [dm-devel] " Dave Chinner
2023-05-26 1:36 ` Dave Chinner
2023-05-26 2:35 ` [dm-devel] " Sarthak Kukreti
2023-05-26 2:35 ` Sarthak Kukreti
2023-05-26 15:56 ` [dm-devel] " Brian Foster
2023-05-26 15:56 ` Brian Foster
2023-05-25 16:19 ` [dm-devel] " Brian Foster
2023-05-25 16:19 ` Brian Foster
2023-05-26 9:37 ` [dm-devel] " Dave Chinner
2023-05-26 9:37 ` Dave Chinner
2023-05-26 11:04 ` [dm-devel] " Joe Thornber
2023-05-26 23:45 ` Dave Chinner
2023-05-26 23:45 ` Dave Chinner
2023-05-30 7:27 ` [dm-devel] " Joe Thornber
2023-05-30 14:02 ` Mike Snitzer
2023-05-30 14:02 ` Mike Snitzer
2023-05-30 14:55 ` [dm-devel] " Joe Thornber
2023-05-30 15:28 ` Mike Snitzer
2023-05-30 15:28 ` Mike Snitzer
2023-06-02 18:44 ` [dm-devel] " Sarthak Kukreti
2023-06-02 18:44 ` Sarthak Kukreti
2023-06-02 21:50 ` [dm-devel] " Mike Snitzer
2023-06-02 21:50 ` Mike Snitzer
2023-06-03 0:52 ` [dm-devel] " Dave Chinner
2023-06-03 0:52 ` Dave Chinner
2023-06-03 15:57 ` [dm-devel] " Mike Snitzer
2023-06-03 15:57 ` Mike Snitzer
2023-06-05 21:14 ` [dm-devel] " Sarthak Kukreti
2023-06-05 21:14 ` Sarthak Kukreti
2023-06-07 2:15 ` [dm-devel] " Dave Chinner
2023-06-07 2:15 ` Dave Chinner
2023-06-07 23:27 ` [dm-devel] " Mike Snitzer
2023-06-07 23:27 ` Mike Snitzer
2023-06-09 20:31 ` [dm-devel] " Mike Snitzer
2023-06-09 20:31 ` Mike Snitzer
2023-06-09 21:54 ` [dm-devel] " Dave Chinner
2023-06-09 21:54 ` Dave Chinner
2023-10-07 1:30 ` [dm-devel] " Sarthak Kukreti
2023-10-07 1:30 ` Sarthak Kukreti
2023-06-07 2:01 ` [dm-devel] " Dave Chinner
2023-06-07 2:01 ` Dave Chinner
2023-06-07 23:50 ` [dm-devel] " Mike Snitzer
2023-06-07 23:50 ` Mike Snitzer
2023-06-09 3:32 ` [dm-devel] " Dave Chinner
2023-06-09 3:32 ` Dave Chinner
2023-06-08 2:03 ` [dm-devel] " Martin K. Petersen
2023-06-08 2:03 ` Martin K. Petersen
2023-06-09 0:10 ` [dm-devel] " Dave Chinner
2023-06-09 0:10 ` Dave Chinner
2023-05-26 15:47 ` [dm-devel] " Brian Foster
2023-05-26 15:47 ` Brian Foster
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=ZIJyIOIPx+jE9/iv@redhat.com \
--to=snitzer@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=bfoster@redhat.com \
--cc=bvanassche@google.com \
--cc=djwong@kernel.org \
--cc=dm-devel@redhat.com \
--cc=ejt@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=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.