Re: [PATCH 0/2] iomap: small block problems

[Christoph Hellwig <hch@infradead.org>]

On Mon, Jun 28, 2021 at 06:39:09PM +0100, Matthew Wilcox wrote:
> Not hugely happy with either of these options, tbh.  I'd rather we apply
> a patch akin to this one (plucked from the folio tree), so won't apply:

> so permit pages without an iop to enter writeback and create an iop
> *then*.  Would that solve your problem?

It is the right thing to do, especially when combined with a feature
patch to not bother to create the iomap_page structure on small
block size file systems when the extent covers the whole page.

> 
> > (3) We're not yet using iomap_page_mkwrite, so iomap_page objects don't
> > get created on .page_mkwrite, either.  Part of the reason is that
> > iomap_page_mkwrite locks the page and then calls into the filesystem for
> > uninlining and for allocating backing blocks.  This conflicts with the
> > gfs2 locking order: on gfs2, transactions must be started before locking
> > any pages.  We can fix that by calling iomap_page_create from
> > gfs2_page_mkwrite, or by doing the uninlining and allocations before
> > calling iomap_page_mkwrite.  I've implemented option 2 for now; see
> > here:
> 
> I think this might also solve this problem?

We'll still need to create the iomap_page structure for page_mkwrite
if there is an extent boundary inside the page.