Messages in this thread | | | Subject | Re: [PATCH 2.6.3-rc2-mm1] __block_write_full patch | From | Daniel McNeil <> | Date | 13 Feb 2004 15:30:39 -0800 |
| |
On Fri, 2004-02-13 at 14:38, Andrew Morton wrote:
> My suspicion is that the real problem is that mpage_writepages() moved the > page onto mapping->locked_pages while there is buffer-level I/O in flight > (that's OK). But PG_writeback is not set because writepage never started > any I/O. So filemap_fdatawait() never waits for the ext3-initiated > buffer-level I/O.
kjournald was calling ll_rw_block() with a bunch of bh's and PG_writeback was not set.
A subsequent __block_write_full_page() with the page locked, sees that none of the bh(s) for that page are dirty. PG_PageWriteback would be set, unlock_page() and then see no buffers to submit, so clear PG_Page_Writeback (but buffer i/o still in flight). filemap_fdatawait() has nothing to wait for.
I think we agree.
> > If so, there are several ways to fix this:
> c) Change __block_write_full_page() to move the page back onto > mapping->dirty_pages if it was WB_SYNC_NONE and we discovered that the > page had a locked buffer. This way, a subsequent WB_SYNC_ALL will > correctly wait on that buffer. > > Try c), please?
No problem. I will code this up and give it a try.
My only concern is that a racing mpage_writepages(WB_SYNC_NONE) with a mpage_write_pages(WB_SYNC_ALL) from a filemap_write_and_wait. Both could be processing the io_pages list, if the mpage_writepages(WB_SYNC_NONE) moves a page that has locked buffers back to the dirty_pages list, then when the filemap_write_and_wait() calls filemap_fdatawait, it will not wait for the page moved back to the dirty list.
I'll code up the change and run my tests and let you know what happens.
Thanks,
Daniel
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |