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? Mike
