Re: [PATCH 2.6.3-rc2-mm1] __block_write_full patch

[Daniel McNeil]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/