From: Mike Snitzer <snitzer@redhat.com>
To: Sarthak Kukreti <sarthakkukreti@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Joe Thornber <thornber@redhat.com>,
dm-devel@redhat.com, "Michael S. Tsirkin" <mst@redhat.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Jason Wang <jasowang@redhat.com>,
Bart Van Assche <bvanassche@google.com>,
Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
Joe Thornber <ejt@redhat.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Stefan Hajnoczi <stefanha@redhat.com>,
linux-fsdevel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
linux-ext4@vger.kernel.org, Brian Foster <bfoster@redhat.com>,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [dm-devel] [PATCH v7 0/5] Introduce provisioning primitives
Date: Fri, 9 Jun 2023 16:31:41 -0400 [thread overview]
Message-ID: <ZIOMLfMjugGf4C2T@redhat.com> (raw)
In-Reply-To: <ZIESXNF5anyvJEjm@redhat.com>
On Wed, Jun 07 2023 at 7:27P -0400,
Mike Snitzer <snitzer@kernel.org> wrote:
> On Mon, Jun 05 2023 at 5:14P -0400,
> Sarthak Kukreti <sarthakkukreti@chromium.org> wrote:
>
> > On Sat, Jun 3, 2023 at 8:57 AM Mike Snitzer <snitzer@kernel.org> wrote:
> > >
> > > We all just need to focus on your proposal and Joe's dm-thin
> > > reservation design...
> > >
> > > [Sarthak: FYI, this implies that it doesn't really make sense to add
> > > dm-thinp support before Joe's design is implemented. Otherwise we'll
> > > have 2 different responses to REQ_OP_PROVISION. The one that is
> > > captured in your patchset isn't adequate to properly handle ensuring
> > > upper layer (like XFS) can depend on the space being available across
> > > snapshot boundaries.]
> > >
> > Ack. Would it be premature for the rest of the series to go through
> > (REQ_OP_PROVISION + support for loop and non-dm-thinp device-mapper
> > targets)? I'd like to start using this as a reference to suggest
> > additions to the virtio-spec for virtio-blk support and start looking
> > at what an ext4 implementation would look like.
>
> Please drop the dm-thin.c and dm-snap.c changes. dm-snap.c would need
> more work to provide the type of guarantee XFS requires across
> snapshot boundaries. I'm inclined to _not_ add dm-snap.c support
> because it is best to just use dm-thin.
>
> And FYI even your dm-thin patch will be the starting point for the
> dm-thin support (we'll keep attribution to you for all the code in a
> separate patch).
>
> > Fair points, I certainly don't want to derail this conversation; I'd
> > be happy to see this work merged sooner rather than later.
>
> Once those dm target changes are dropped I think the rest of the
> series is fine to go upstream now. Feel free to post a v8.
FYI, I've made my latest code available in this
'dm-6.5-provision-support' branch (based on 'dm-6.5'):
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-6.5-provision-support
It's what v8 should be plus the 2 dm-thin patches (that I don't think
should go upstream yet, but are theoretically useful for Dave and
Joe).
The "dm thin: complete interface for REQ_OP_PROVISION support" commit
establishes all the dm-thin interface I think is needed. The FIXME in
process_provision_bio() (and the patch header) cautions against upper
layers like XFS using this dm-thinp support quite yet.
Otherwise we'll have the issue where dm-thinp's REQ_OP_PROVISION
support initially doesn't provide the guarantee that XFS needs across
snapshots (which is: snapshots inherit all previous REQ_OP_PROVISION).
Mike
--
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>
Cc: Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@infradead.org>,
Joe Thornber <thornber@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Jason Wang <jasowang@redhat.com>,
Bart Van Assche <bvanassche@google.com>,
Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org, Joe Thornber <ejt@redhat.com>,
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, Theodore Ts'o <tytso@mit.edu>,
linux-ext4@vger.kernel.org, Brian Foster <bfoster@redhat.com>,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH v7 0/5] Introduce provisioning primitives
Date: Fri, 9 Jun 2023 16:31:41 -0400 [thread overview]
Message-ID: <ZIOMLfMjugGf4C2T@redhat.com> (raw)
In-Reply-To: <ZIESXNF5anyvJEjm@redhat.com>
On Wed, Jun 07 2023 at 7:27P -0400,
Mike Snitzer <snitzer@kernel.org> wrote:
> On Mon, Jun 05 2023 at 5:14P -0400,
> Sarthak Kukreti <sarthakkukreti@chromium.org> wrote:
>
> > On Sat, Jun 3, 2023 at 8:57 AM Mike Snitzer <snitzer@kernel.org> wrote:
> > >
> > > We all just need to focus on your proposal and Joe's dm-thin
> > > reservation design...
> > >
> > > [Sarthak: FYI, this implies that it doesn't really make sense to add
> > > dm-thinp support before Joe's design is implemented. Otherwise we'll
> > > have 2 different responses to REQ_OP_PROVISION. The one that is
> > > captured in your patchset isn't adequate to properly handle ensuring
> > > upper layer (like XFS) can depend on the space being available across
> > > snapshot boundaries.]
> > >
> > Ack. Would it be premature for the rest of the series to go through
> > (REQ_OP_PROVISION + support for loop and non-dm-thinp device-mapper
> > targets)? I'd like to start using this as a reference to suggest
> > additions to the virtio-spec for virtio-blk support and start looking
> > at what an ext4 implementation would look like.
>
> Please drop the dm-thin.c and dm-snap.c changes. dm-snap.c would need
> more work to provide the type of guarantee XFS requires across
> snapshot boundaries. I'm inclined to _not_ add dm-snap.c support
> because it is best to just use dm-thin.
>
> And FYI even your dm-thin patch will be the starting point for the
> dm-thin support (we'll keep attribution to you for all the code in a
> separate patch).
>
> > Fair points, I certainly don't want to derail this conversation; I'd
> > be happy to see this work merged sooner rather than later.
>
> Once those dm target changes are dropped I think the rest of the
> series is fine to go upstream now. Feel free to post a v8.
FYI, I've made my latest code available in this
'dm-6.5-provision-support' branch (based on 'dm-6.5'):
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-6.5-provision-support
It's what v8 should be plus the 2 dm-thin patches (that I don't think
should go upstream yet, but are theoretically useful for Dave and
Joe).
The "dm thin: complete interface for REQ_OP_PROVISION support" commit
establishes all the dm-thin interface I think is needed. The FIXME in
process_provision_bio() (and the patch header) cautions against upper
layers like XFS using this dm-thinp support quite yet.
Otherwise we'll have the issue where dm-thinp's REQ_OP_PROVISION
support initially doesn't provide the guarantee that XFS needs across
snapshots (which is: snapshots inherit all previous REQ_OP_PROVISION).
Mike
next prev parent reply other threads:[~2023-06-09 20:31 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 ` [dm-devel] " Mike Snitzer
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 ` Mike Snitzer [this message]
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=ZIOMLfMjugGf4C2T@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=david@fromorbit.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=thornber@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.