ext4 stable page writes question
According to stable write assumptions (1d1d1a767206fb) grab_cache_page_write_begin() now calls relaxed method wait_for_stable_page() which will wait for writeback to finish only if bdi demand that. Commit message states that ext4 may not wait
But there are a lot of write-paths where we expect that:
BUG_ON(!PageLocked(page));
BUG_ON(PageWriteback(page));
And the only reason we avoid this bugon is because of commit 47564bfb95b which use following trick to avoid lock inversion over journal_start:
page = grab_cache_page_write_begin()unlock_page(page);ext4_journal_start()lock_page(page);wait_on_page_writeback(page); <<<< unconditional wait
So as far as I understand this was done just by occasion because ext4_page_mkwrite() use wait_for_stable_page().
So here is my question: Do we have to wait for page's writeback to finish for all write paths in ext4 code or we may use wait_for_stable_page() and should cleanup all places where we may trigger BUG_ON(PageWriteback(page));
Quoted 3 lines · Dmitry Monakhov
According to stable write assumptions (
1d1d1a767206fb)grab_cache_page_write_begin()now calls relaxed methodwait_for_stable_page()which will wait for writeback to finish only if bdi demand that.
Yes.
Quoted 4 lines
Commit message states that ext4 may not wait But there are a lot of write-paths where we expect that:
BUG_ON(!PageLocked(page)); BUG_ON(PageWriteback(page));
Really? The only places I can find are in writeback path and there we
have wait_on_page_writeback() (either in write_cache_pages() or in ext4_da_writepages()).
Quoted 7 lines
And the only reason we avoid this bugon is because of commit
47564bfb95bwhich use following trick to avoid lock inversion overjournal_start:
page =grab_cache_page_write_begin()unlock_page(page);ext4_journal_start()lock_page(page);wait_on_page_writeback(page); <<<< unconditional wait
No, I think this is really independent. ext4 should be fine when write &
writeback are running in parallel for a page.
Quoted 7 lines
So as far as I understand this was done just by occasion because
ext4_page_mkwrite()usewait_for_stable_page().So here is my question: Do we have to wait for page's writeback to finish for all write paths in ext4 code or we may use
wait_for_stable_page()and should cleanup all places where we may trigger BUG_ON(PageWriteback(page));
If there's any such place, please tell me how we could trigger it...
Honza
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
Quoted 24 lines · Jan Kara
Quoted 3 lines · Dmitry Monakhov
According to stable write assumptions (
1d1d1a767206fb)grab_cache_page_write_begin()now calls relaxed methodwait_for_stable_page()which will wait for writeback to finish only if bdi demand that.Yes.
Quoted 4 lines
Commit message states that ext4 may not wait But there are a lot of write-paths where we expect that:
BUG_ON(!PageLocked(page)); BUG_ON(PageWriteback(page));Really? The only places I can find are in writeback path and there we
havewait_on_page_writeback()(either inwrite_cache_pages()or inext4_da_writepages()).Quoted 7 lines
And the only reason we avoid this bugon is because of commit
47564bfb95bwhich use following trick to avoid lock inversion overjournal_start:
page =grab_cache_page_write_begin()unlock_page(page);ext4_journal_start()lock_page(page);wait_on_page_writeback(page); <<<< unconditional waitNo, I think this is really independent. ext4 should be fine when write &
writeback are running in parallel for a page.
Quoted 8 lines
Quoted 7 lines
So as far as I understand this was done just by occasion because
ext4_page_mkwrite()usewait_for_stable_page().So here is my question: Do we have to wait for page's writeback to finish for all write paths in ext4 code or we may use
wait_for_stable_page()and should cleanup all places where we may trigger BUG_ON(PageWriteback(page));If there's any such place, please tell me how we could trigger it...
move_extent.c:mext_page_mkuptodate() expect that.
IMHO it is reasonable to force behavior here even if we may not do that on other places because defragmentation code should be 101% reliable and performance is not important here.
Quoted 5 lines
Honza
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR