Re: ext3 IO latency measurements (was: Linux 2.6.29)

Jan Kara
2009-03-27T21:27:03Z

On Thu 26-03-09 11:35:29, Andrew Morton wrote:
>
> The patch looks OK to me.
>
> On Thu, 26 Mar 2009 19:11:06 +0100 Jan Kara <jack@suse.cz> wrote:
>
> > @@ -1490,6 +1494,16 @@ static int ext3_ordered_writepage(struct page *page,
> > if (ext3_journal_current_handle())
> > goto out_fail;
> >
> > + if (!page_has_buffers(page)) {
> > + create_empty_buffers(page, inode->i_sb->s_blocksize,
> > + (1 << BH_Dirty)|(1 << BH_Uptodate));
>
> This will attach dirty buffers to a clean page, which is an invalid
> state (but OK if we immediately fix it up).
Yes - actually the page has been dirty just the moment before when we run
clear_page_dirty_for_io() - and at this function could have also created
the clean page with dirty buffers...

> > + } else if (!walk_page_buffers(NULL, page_buffers(page), 0, PAGE_CACHE_SIZE, NULL, buffer_unmapped)) {
> > + /* Provide NULL instead of get_block so that we catch bugs if buffers weren't really mapped */
> > + return block_write_full_page(page, NULL, wbc);
> > + }
> > + page_bufs = page_buffers(page);
> > +
> > +
> > handle = ext3_journal_start(inode, ext3_writepage_trans_blocks(inode));
> >
> > if (IS_ERR(handle)) {
>
> And if this error happens we'll go on to run
> redirty_page_for_writepage() which will do the right thing.
>
> However if PageMappedToDisk() is working right, we should be able to
> avoid that newly-added buffer walk. Possibly SetPageMappedToDisk()
> isn't being run in all the right places though, dunno.
Yes, SetPageMappedToDisk is set only by block_read_full_page(),
mpage_readpage() and nobh_write_begin(). Obviously not enough... It would
be nice to improve that but that's another story...

Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR