Re: ext3_ordered_writepage() questions

[Badari Pulavarty]

Andrew Morton wrote:

> Badari Pulavarty <pbadari@xxxxxxxxxx> 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.
In  non-block allocation case, what metadata are we journaling in 
writepage() ?
block allocation happend in prepare_write() and commit_write() journaled the
transaction. All the meta data updates should be done there.  What JBD 
commit
are you refering to here ?

> 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().

Yes. You are right. I never realized that, we call 
prepare_write()/commit_write() for
each write. I was under the impression that we do it only on the first 
instantiation of
the page. I will take a closer look at it.

The reasons for looking at writepage() are:

- want to support writepages()  for ext3. Last time when I tried, ran into
page->lock and journal_start() deadlock. Thats why I want to understand the
journalling better and clean it up while looking at it.

- eventually, I want to add delayed allocation to make use of multiblock 
allocation.
Right now, we can't make use of multiblock allocation for buffered mode :(

Thanks,
Badari



-
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/