On Tue, Apr 30, 2019 at 05:39:28PM +0200, Andreas Gruenbacher wrote:
> On Tue, 30 Apr 2019 at 17:33, Darrick J. Wong <darrick.w...@oracle.com> 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.
Ah, ok.
> > 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.
Ok, I'll take the first four patches through the iomap branch and cc you
on the pull request.
--D
>
> Thanks,
> Andreas
