On Tue, May 30 2023 at 3:27P -0400,
Joe Thornber <thornber@xxxxxxxxxx> wrote:
> On Sat, May 27, 2023 at 12:45 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> > On Fri, May 26, 2023 at 12:04:02PM +0100, Joe Thornber wrote:
> >
> > > 1) We have an api (ioctl, bio flag, whatever) that lets you
> > > reserve/guarantee a region:
> > >
> > > int reserve_region(dev, sector_t begin, sector_t end);
> >
> > A C-based interface is not sufficient because the layer that must do
> > provsioning is not guaranteed to be directly under the filesystem.
> > We must be able to propagate the request down to the layers that
> > need to provision storage, and that includes hardware devices.
> >
> > e.g. dm-thin would have to issue REQ_PROVISION on the LBA ranges it
> > allocates in it's backing device to guarantee that the provisioned
> > LBA range it allocates is also fully provisioned by the storage
> > below it....
> >
>
> Fine, bio flag it is.
>
>
> >
> > > This api should be used minimally, eg, critical FS metadata only.
> >
> >
> >
> > Plan for having to support tens of GBs of provisioned space in
> > filesystems, not tens of MBs....
> >
>
> Also fine.
>
>
> I think there's a 2-3 solid days of coding to fully implement
> > REQ_PROVISION support in XFS, including userspace tool support.
> > Maybe a couple of weeks more to flush the bugs out before it's
> > largely ready to go.
> >
> > So if there's buy in from the block layer and DM people for
> > REQ_PROVISION as described, then I'll definitely have XFS support
> > ready for you to test whenever dm-thinp is ready to go.
> >
>
> Great, this is what I wanted to hear. I guess we need an ack from the
> block guys and then I'll get started.
The block portion is where this discussion started (in the context of
this thread's patchset, now at v7).
During our discussion I think there were 2 gaps identified with this
patchset:
1) provisioning should be opt-in, and we need a clear flag that upper
layers look for to know if REQ_PROVISION available
- we do get this with the max_provision_sectors = 0 default, is
checking queue_limits (via queue_max_provision_sectors)
sufficient for upper layers like xfs?
2) DM thinp needs REQ_PROVISION passdown support
- also dm_table_supports_provision() needs to be stricter by
requiring _all_ underlying devices support provisioning?
Bonus dm-thinp work: add ranged REQ_PROVISION support to reduce number
of calls (and bios) block core needs to pass to dm thinp.
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).
Mike
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
