On Tue, 9 Apr 2019 at 14:15, Christoph Hellwig wrote:
> On Mon, Apr 08, 2019 at 03:44:05PM +0200, Jan Kara wrote:
> > > We won't be able to do a log flush while another transaction is
> > > active, but that's what's needed to clean dirty pages. iomap doesn't
> > > allow us to put the block
On Mon, Apr 08, 2019 at 03:44:05PM +0200, Jan Kara wrote:
> > We won't be able to do a log flush while another transaction is
> > active, but that's what's needed to clean dirty pages. iomap doesn't
> > allow us to put the block allocation into a separate transaction from
> > the page writes; for
On Mon 08-04-19 10:53:34, Andreas Gruenbacher wrote:
> On Sun, 7 Apr 2019 at 09:32, Christoph Hellwig wrote:
> >
> > [adding Jan and linux-mm]
> >
> > On Fri, Mar 29, 2019 at 11:13:00PM +0100, Andreas Gruenbacher wrote:
> > > > But what is the requirement to do this in writeback context? Can't
>
On Sun, 7 Apr 2019 at 09:32, Christoph Hellwig wrote:
>
> [adding Jan and linux-mm]
>
> On Fri, Mar 29, 2019 at 11:13:00PM +0100, Andreas Gruenbacher wrote:
> > > But what is the requirement to do this in writeback context? Can't
> > > we move it out into another context instead?
> >
> > Indeed,
[adding Jan and linux-mm]
On Fri, Mar 29, 2019 at 11:13:00PM +0100, Andreas Gruenbacher wrote:
> > But what is the requirement to do this in writeback context? Can't
> > we move it out into another context instead?
>
> Indeed, this isn't for data integrity in this case but because the
> dirty
On Thu, 28 Mar 2019 at 17:51, Christoph Hellwig wrote:
> On Thu, Mar 21, 2019 at 02:13:04PM +0100, Andreas Gruenbacher wrote:
> > Hi Christoph,
> >
> > we need your help fixing a gfs2 deadlock involving iomap. What's going
> > on is the following:
> >
> > * During iomap_file_buffered_write,
On Thu, Mar 21, 2019 at 02:13:04PM +0100, Andreas Gruenbacher wrote:
> Hi Christoph,
>
> we need your help fixing a gfs2 deadlock involving iomap. What's going
> on is the following:
>
> * During iomap_file_buffered_write, gfs2_iomap_begin grabs the log flush
> lock and keeps it until
On 3/22/19 12:21 AM, Andreas Gruenbacher wrote:
On Fri, 22 Mar 2019 at 00:01, Andreas Gruenbacher wrote:
On Thu, 21 Mar 2019 at 22:43, Dave Chinner wrote:
The problem is calling balance_dirty_pages() inside the
->iomap_begin/->iomap_end calls and not that it is called by the
iomap
On Fri, 22 Mar 2019 at 00:01, Andreas Gruenbacher wrote:
> On Thu, 21 Mar 2019 at 22:43, Dave Chinner wrote:
> > The problem is calling balance_dirty_pages() inside the
> > ->iomap_begin/->iomap_end calls and not that it is called by the
> > iomap infrastructure itself, right?
> >
> > Is so, I'd
On Thu, 21 Mar 2019 at 22:43, Dave Chinner wrote:
> The problem is calling balance_dirty_pages() inside the
> ->iomap_begin/->iomap_end calls and not that it is called by the
> iomap infrastructure itself, right?
>
> Is so, I'd prefer to see this in iomap_apply() after the call to
>
On Thu, Mar 21, 2019 at 02:13:04PM +0100, Andreas Gruenbacher wrote:
> Hi Christoph,
>
> we need your help fixing a gfs2 deadlock involving iomap. What's going
> on is the following:
>
> * During iomap_file_buffered_write, gfs2_iomap_begin grabs the log flush
> lock and keeps it until
Hi Christoph,
we need your help fixing a gfs2 deadlock involving iomap. What's going
on is the following:
* During iomap_file_buffered_write, gfs2_iomap_begin grabs the log flush
lock and keeps it until gfs2_iomap_end. It currently always does that
even though there is no point other than
12 matches
Mail list logo
