From: Badari Pulavarty <pbadari@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: sct@redhat.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, jack@suse.cz
Subject: Re: ext3_ordered_writepage() questions
Date: Thu, 09 Mar 2006 16:36:53 -0800 [thread overview]
Message-ID: <4410CA25.2090400@us.ibm.com> (raw)
In-Reply-To: 20060309153550.379516e1.akpm@osdl.org
Andrew Morton wrote:
>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.
>
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
next prev parent reply other threads:[~2006-03-10 0:37 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-08 0:19 [RFC PATCH 0/3] VFS changes to collapse all the vectored and AIO support Badari Pulavarty
2006-03-08 0:22 ` [PATCH 1/3] Vectorize aio_read/aio_write methods Badari Pulavarty
2006-03-08 12:44 ` christoph
2006-03-08 0:23 ` [PATCH 2/3] Remove readv/writev methods and use aio_read/aio_write instead Badari Pulavarty
2006-03-08 12:45 ` christoph
2006-03-08 16:26 ` Badari Pulavarty
2006-03-08 0:24 ` [PATCH 3/3] Zach's core aio changes to support vectored AIO Badari Pulavarty
2006-03-08 3:37 ` Benjamin LaHaise
2006-03-08 16:34 ` Badari Pulavarty
2006-03-08 12:47 ` [RFC PATCH 0/3] VFS changes to collapse all the vectored and AIO support christoph
2006-03-08 16:24 ` Badari Pulavarty
2006-03-09 16:17 ` ext3_ordered_writepage() questions Badari Pulavarty
2006-03-09 23:35 ` Andrew Morton
2006-03-10 0:36 ` Badari Pulavarty [this message]
2006-03-16 18:09 ` Theodore Ts'o
2006-03-16 18:22 ` Badari Pulavarty
2006-03-16 21:04 ` Theodore Ts'o
2006-03-16 21:57 ` Badari Pulavarty
2006-03-16 22:05 ` Jan Kara
2006-03-16 23:45 ` Badari Pulavarty
2006-03-17 0:44 ` Theodore Ts'o
2006-03-17 0:54 ` Andreas Dilger
2006-03-17 17:05 ` Stephen C. Tweedie
2006-03-17 21:32 ` Badari Pulavarty
2006-03-17 22:22 ` Stephen C. Tweedie
2006-03-17 22:38 ` Badari Pulavarty
2006-03-17 23:23 ` Mingming Cao
2006-03-20 17:05 ` Stephen C. Tweedie
2006-03-18 2:57 ` Suparna Bhattacharya
2006-03-18 3:02 ` Suparna Bhattacharya
2006-03-17 15:32 ` Jamie Lokier
2006-03-17 21:50 ` Stephen C. Tweedie
2006-03-17 22:11 ` Theodore Ts'o
2006-03-17 22:44 ` Jamie Lokier
2006-03-18 23:40 ` Theodore Ts'o
2006-03-19 2:36 ` Jamie Lokier
2006-03-19 5:28 ` Chris Adams
2006-03-20 2:18 ` Theodore Ts'o
2006-03-20 16:26 ` Stephen C. Tweedie
2006-03-17 22:23 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4410CA25.2090400@us.ibm.com \
--to=pbadari@us.ibm.com \
--cc=akpm@osdl.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox