On Tue, 30 Apr 2019 at 17:33, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
> On Tue, Apr 30, 2019 at 12:09:34AM +0200, Andreas Gruenbacher wrote:
> > Since commit 64bc06bb32ee ("gfs2: iomap buffered write support"), gfs2 is doing
> > buffered writes by starting a transaction in iomap_begin, writing a range of
> > pages, and ending that transaction in iomap_end. This approach suffers from
> > two problems:
> >
> > (1) Any allocations necessary for the write are done in iomap_begin, so when
> > the data aren't journaled, there is no need for keeping the transaction open
> > until iomap_end.
> >
> > (2) Transactions keep the gfs2 log flush lock held. When
> > iomap_file_buffered_write calls balance_dirty_pages, this can end up calling
> > gfs2_write_inode, which will try to flush the log. This requires taking the
> > log flush lock which is already held, resulting in a deadlock.
>
> /me wonders how holding the log flush lock doesn't seriously limit
> performance, but gfs2 isn't my fight so I'll set that aside and assume
> that a patch S-o-B'd by both maintainers is ok. :)
This only affects inline and journaled data, not standard writes, so
it's not quite as bad as it looks.
> How should we merge this patch #5? It doesn't touch fs/iomap.c itself,
> so do you want me to pull it into the iomap branch along with the
> previous four patches? That would be fine with me (and easier than a
> multi-tree merge mess)...
I'd prefer to get this merged via the gfs2 tree once the iomap fixes
have been pulled.
Thanks,
Andreas
