On Tue, May 30, 2023 at 8:28 AM Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > On Tue, May 30 2023 at 10:55P -0400, > Joe Thornber <thornber@xxxxxxxxxx> wrote: > > > On Tue, May 30, 2023 at 3:02 PM Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > > > > > > Also Joe, for you proposed dm-thinp design where you distinquish > > > between "provision" and "reserve": Would it make sense for REQ_META > > > (e.g. all XFS metadata) with REQ_PROVISION to be treated as an > > > LBA-specific hard request? Whereas REQ_PROVISION on its own provides > > > more freedom to just reserve the length of blocks? (e.g. for XFS > > > delalloc where LBA range is unknown, but dm-thinp can be asked to > > > reserve space to accomodate it). > > > > > > > My proposal only involves 'reserve'. Provisioning will be done as part of > > the usual io path. > > OK, I think we'd do well to pin down the top-level block interfaces in > question. Because this patchset's block interface patch (2/5) header > says: > > "This patch also adds the capability to call fallocate() in mode 0 > on block devices, which will send REQ_OP_PROVISION to the block > device for the specified range," > > So it wires up blkdev_fallocate() to call blkdev_issue_provision(). A > user of XFS could then use fallocate() for user data -- which would > cause thinp's reserve to _not_ be used for critical metadata. > > The only way to distinquish the caller (between on-behalf of user data > vs XFS metadata) would be REQ_META? > > So should dm-thinp have a REQ_META-based distinction? Or just treat > all REQ_OP_PROVISION the same? > I'm in favor of a REQ_META-based distinction. Does that imply that REQ_META also needs to be passed through the block/filesystem stack (eg. REQ_OP_PROVION + REQ_META on a loop device translates to a fallocate(<insert meta flag name>) to the underlying file)? <bikeshed> I think that might have applications beyond just provisioning: currently, for stacked filesystems (eg filesystems residing in a file on top of another filesystem), even if the upper filesystem issues read/write requests with REQ_META | REQ_PRIO, these flags are lost in translation at the loop device layer. A flag like the above would allow the prioritization of stacked filesystem metadata requests. </bikeshed> Bringing the discussion back to this series for a bit, I'm still waiting on feedback from the Block maintainers before sending out v8 (which at the moment, only have a s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/g). I believe from the conversation most of the above is follow up work, but please let me know if you'd prefer I add some of this to the current series! Best Sarthak > Mike
