From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, sandeen@redhat.com
Subject: Re: Delayed allocation and page_lock vs transaction start ordering
Date: Tue, 27 May 2008 20:41:28 +0530 [thread overview]
Message-ID: <20080527151128.GA13237@skywalker> (raw)
In-Reply-To: <20080527124312.GG5178@duck.suse.cz>
On Tue, May 27, 2008 at 02:43:12PM +0200, Jan Kara wrote:
> On Mon 26-05-08 23:30:43, Aneesh Kumar K.V wrote:
>
> > I have got another question now related to page_mkwrite. AFAIU writepage
> > writeout dirty buffer_heads. It also looks at whether the pages are
> > dirty or not. In the page_mkwrite callback both are not true. ie we call
> > set_page_dirty from do_wp_page after calling page_mkwrite. I haven't
> > verified whether the above is correct or not. Just thinking reading the
> > code.
> Writepage call itself doesn't look at whether the page is dirty or not -
> that flag is already cleared when writepage is called. You are right that
> the page is marked dirty only after page_mkwrite is called - the meaning of
> page_mkwrite() call is roughly "someone wants to do the first write to this
> page via mmap, prepare filesystem for that". But we don't really care
> whether the page is dirty or not - we know it carries correct data (it is
> uptodate) and so we can write it if we want (and need).
>
I am looking at __block_write_full_page and we have
if (!buffer_mapped(bh) && buffer_dirty(bh)) {
WARN_ON(bh->b_size != blocksize);
err = get_block(inode, block, bh, 1);
if (err)
ie, we do get_block only if the buffer_head is dirty. So I am bit
doubtful whether we are actually allocating blocks via page_mkwrite.
-aneesh
next prev parent reply other threads:[~2008-05-27 15:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-15 16:14 Delayed allocation and page_lock vs transaction start ordering Jan Kara
2008-04-15 17:58 ` Badari Pulavarty
2008-04-16 9:26 ` Jan Kara
2008-04-15 18:08 ` Mingming Cao
2008-04-15 23:28 ` Mingming Cao
2008-04-15 23:33 ` Mingming Cao
2008-04-16 10:35 ` Jan Kara
2008-04-16 18:24 ` Mingming Cao
2008-04-16 19:55 ` Badari Pulavarty
2008-04-16 9:38 ` Jan Kara
2008-04-18 18:54 ` Andreas Dilger
2008-04-18 19:38 ` Mingming Cao
2008-04-21 17:13 ` Jan Kara
2008-05-21 8:21 ` Aneesh Kumar K.V
2008-05-26 17:21 ` Jan Kara
2008-05-26 18:00 ` Aneesh Kumar K.V
2008-05-27 12:43 ` Jan Kara
2008-05-27 15:11 ` Aneesh Kumar K.V [this message]
2008-05-28 9:33 ` Jan Kara
2008-05-28 9:43 ` Aneesh Kumar K.V
2008-05-28 10:33 ` Jan Kara
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=20080527151128.GA13237@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.