[Top] [All Lists]

Re: [PATCH V2] Re-dirty pages on ENOSPC when converting delayed allocati

To: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>
Subject: Re: [PATCH V2] Re-dirty pages on ENOSPC when converting delayed allocations
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 10 Oct 2008 09:48:32 +1100
In-reply-to: <20081009122726.GH9597@disturbed>
Mail-followup-to: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>
References: <48EB1ABD.3020503@sgi.com> <20081009122726.GH9597@disturbed>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Oct 09, 2008 at 11:27:26PM +1100, Dave Chinner wrote:
> On Tue, Oct 07, 2008 at 06:15:57PM +1000, Lachlan McIlroy wrote:
> > If we get an error in xfs_page_state_convert() - and it's not EAGAIN - then
> > we throw away the dirty page without converting the delayed allocation.  
> > This
> > leaves delayed allocations that can never be removed and confuses code that
> > expects a flush of the file to clear them.  We need to re-dirty the page on
> > error so we can try again later or report that the flush failed.
> Actually, those delalloc pages can be removed - they just need to
> be handled in ->releasepage. The problem there is that the
> delalloc state is checked by looking at the bufferhead, and by
> the time we get to ->releasepage the buffer heads have already gone
> through discard_buffer() and lost the buffer_delay() flag.
> IIRC I had a patch that did the delalloc conversion correctly in
> ->releasepage by utilising a custom ->invalidatepage callouut, but
> the performance overhead was very bad because it is done a page at a
> time. ISTR even posting it to oss....

FWIW, here's the discussion:


I'm not saying that we Ñhould be fixing this right now, but this
is the underlying problem that is causing the direct I/O read
to trip over stale delalloc extents once they've been invalidated.


Dave Chinner

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