Re: ext3_ordered_writepage() questions

[Andrew Morton <akpm@osdl.org>]

Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> Hi,
> 
> I am trying to cleanup ext3_ordered and ext3_writeback_writepage() routines.
> I am confused on what ext3_ordered_writepage() is currently doing ? I hope
> you can help me understand it little better.
> 
> 1) Why do we do journal_start() all the time ?

Because we're lame.

> 2) Why do we call journal_dirty_data_fn() on the buffers ? We already
> issued IO on all those buffers() in block_full_write_page(). Why do we
> need to add them to transaction ?  I understand we need to do this for
> block allocation case. But do we need it for non-allocation case also ?

Yup.  Ordered-mode JBD commit needs to write and wait upon all dirty
file-data buffers prior to journalling the metadata.  If we didn't run
journal_dirty_data_fn() against those buffers then they'd still be under
I/O after commit had completed.

Consequently a crash+recover would occasionally allow a read() to read
uninitialised data blocks - those blocks for which we had a) started the
I/O, b) journalled the metadata which refers to that block and c) not yet
completed the I/O when the crash happened.

Now, if the write was known to be an overwrite then we know that the block
isn't uninitialised, so we could perhaps avoid writing that block in the
next commit - just let pdflush handle it.  We'd need to work out whether a
particular block has initialised data on-disk under it when we dirty it,
then track that all the way through to writepage.  It's all possible, and
adds a significant semantic change to ordered-mode.

If that change offered significant performance benefits then yeah, we could
scratch our heads over it.

But I think if you're looking for CPU consumption reductions, you'd be much
better off attacking prepare_write() and commit_write(), rather than
writepage().