[Top] [All Lists]

Re: [PATCH 0/2] Improve writeout pattern from xfs_flush_pages()

To: Jan Kara <jack@xxxxxxx>
Subject: Re: [PATCH 0/2] Improve writeout pattern from xfs_flush_pages()
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 4 Aug 2011 06:42:10 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
In-reply-to: <20110804103616.GF17196@xxxxxxxxxxxxx>
References: <1312404545-15400-1-git-send-email-jack@xxxxxxx> <20110803214206.GA20477@xxxxxxxxxxxxx> <20110804103616.GF17196@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Aug 04, 2011 at 12:36:16PM +0200, Jan Kara wrote:
> > The first one actually is a synchronous writeout, just implemented in
> > a rather odd way by doing the xfs_ioend_wait right after it, so your
> > change is actively harmful for it.
>   Oh, right. BTW cannot be truncate livelocked on a busy file because of
> that xfs_ioend_wait()?

Not really.  We requite the iolock for new writes to start, and truncate
holds it exclusively.  But I'm working on a series for 3.2 to remove
xfs_ioend_wait and just rely on inode_dio_wait for direct I/O, so it
will be gone soon.  At this point I'll also have to switch to
filemap_write_and_wait_range for this caller.

> > The third one is opportunistic writeout if a file got truncated down on
> > final release.  filemap_flush probably is fine here, but there's no need
> > for a range version.  If you replace it with filemap_flush please also
> > kill the useless wrapper while you're at it.
>   Do you mean xfs_flush_pages()? OK, I can do that.

Yes, xfs_flush_pages should go - at least he async version and its
abuse of the buffer flags.

<Prev in Thread] Current Thread [Next in Thread>