On Mon, Jun 28, 2021 at 8:07 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > 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. Yes, but the iop wouldn't need to be allocated in page_mkwrite; that would be taken care of by iomap_writepage / iomap_writepages as in the patch suggested by Matthew, right? Thanks, Andreas
