[lkml]   [2004]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2.6.3-rc2-mm1] __block_write_full patch
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.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:00    [W:0.044 / U:28.392 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site