On Fri, Jun 09, 2023 at 04:31:41PM -0400, Mike Snitzer wrote: > On Wed, Jun 07 2023 at 7:27P -0400, > Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > On Mon, Jun 05 2023 at 5:14P -0400, > > Sarthak Kukreti <sarthakkukreti@xxxxxxxxxxxx> wrote: > > > > > On Sat, Jun 3, 2023 at 8:57 AM Mike Snitzer <snitzer@xxxxxxxxxx> 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). Just tag it with EXPERIMENTAL on recpetion of the first REQ_OP_PROVISION for the device (i.e. dump a log warning), like I'll end up doing with XFS when it detects provisioning support at mount time. We do this all the time to allow merging new features before they are fully production ready - EXPERIMENTAL means you can expect it to mostly work, except when it doesn't, and you know that when it breaks you get to report the bug, help triage it and as a bonus you get to keep the broken bits! $ git grep EXPERIMENTAL fs/xfs fs/xfs/Kconfig: This feature is considered EXPERIMENTAL. Use with caution! fs/xfs/Kconfig: This feature is considered EXPERIMENTAL. Use with caution! fs/xfs/scrub/scrub.c: "EXPERIMENTAL online scrub feature in use. Use at your own risk!"); fs/xfs/xfs_fsops.c: "EXPERIMENTAL online shrink feature in use. Use at your own risk!"); fs/xfs/xfs_super.c: xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own risk"); fs/xfs/xfs_super.c: "EXPERIMENTAL Large extent counts feature in use. Use at your own risk!"); fs/xfs/xfs_xattr.c: "EXPERIMENTAL logged extended attributes feature in use. Use at your own risk!"); $ IOWs, I'll be adding a: "EXPERIMENTAL block device provisioning in use. Use at your own risk!" warning to XFS, and it won't get removed until both the XFS and dm-thinp support is solid and production ready.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
