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 r
While this always looked fishy to me we it needs a good explanation to kill this. I try to remember why Steve did it this way long time ago. The redirty, unlock, return sequence is duplicated after y
Hrm some of that was my fault, ages ago. http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/pagebuf/Attic/page_buf_io.c.diff?r1=1.2;r2=1.3;hideattic=0 I don't remember the details fo why.... ah here's a
Christoph Hellwig wrote: On Thu, Sep 11, 2008 at 06:37:33PM +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 with
Eric Sandeen wrote: Christoph Hellwig wrote: On Thu, Sep 11, 2008 at 06:37:33PM +1000, Lachlan McIlroy wrote: If we get an error in xfs_page_state_convert() - and it's not EAGAIN - then we throw away
Before my change it just cleared the delalloc flag.... I'm not arguing to keep it, just trying to figure out where it's from :) Well, I don't remember how things worked back in 2002 for sure, but pre
So we keep dirty pages around that we can't write back? If we are in a low memory situation and the block device has gone bad, that will prevent memory reclaim from making progress. i.e. if we have a
Dave Chinner wrote: On Thu, Sep 11, 2008 at 06:37:33PM +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 c
The only "temporary" error you can get in writeback is a path failure. IIRC, XVM will give an ENODEV on a path failure, but I don't think that dm-multipath does. Other than that, a write failure is u
Dave Chinner wrote: On Mon, Sep 15, 2008 at 01:22:22PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: So we keep dirty pages around that we can't write back? Yes. If we are in a low memory situati