linux-ext4 - Re: [PATCH v7 0/5] Introduce provisioning primitives

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 30 May 2023 10:02:39 -0400
From:   Mike Snitzer <snitzer@...nel.org>
To:     Joe Thornber <thornber@...hat.com>
Cc:     Dave Chinner <david@...morbit.com>, Jens Axboe <axboe@...nel.dk>,
        linux-block@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Brian Foster <bfoster@...hat.com>,
        Bart Van Assche <bvanassche@...gle.com>,
        linux-kernel@...r.kernel.org, Joe Thornber <ejt@...hat.com>,
        Christoph Hellwig <hch@...radead.org>, dm-devel@...hat.com,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Sarthak Kukreti <sarthakkukreti@...omium.org>,
        linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
        Jason Wang <jasowang@...hat.com>,
        Alasdair Kergon <agk@...hat.com>
Subject: Re: [PATCH v7 0/5] Introduce provisioning primitives

On Tue, May 30 2023 at  3:27P -0400,
Joe Thornber <thornber@...hat.com> wrote:

> On Sat, May 27, 2023 at 12:45 AM Dave Chinner <david@...morbit.com> 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