From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: cmm@us.ibm.com, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: Drop mapped buffer_head check during page_mkwrite
Date: Tue, 25 Aug 2009 22:24:45 -0400 [thread overview]
Message-ID: <20090826022445.GA32712@mit.edu> (raw)
In-Reply-To: <1251210179-7634-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Tue, Aug 25, 2009 at 07:52:59PM +0530, Aneesh Kumar K.V wrote:
> Inorder to check whether the buffer_heads are mapped we need
> to hold page lock. Otherwise a reclaim can cleanup the attached
> buffer_heads. Instead of taking page lock and check whether
> buffer_heads are mapped we let the write_begin/write_end callback
> does the equivalent. It does have a performance impact in that we
> are doing more work if we the buffer_heads are already mapped.
I'm not sure I understand the commit description. From the patch you
are removing the check to see if all of the buffers are mapped. But
the patch isn't moving the check to ext4_write_begin() or
ext4_write_end(). Are you saying the check is already in
ext4_write_begin()? It doesn't seem to be in ext4_write_end().
I see that we do call write_page_buffers() in ext4_write_begin(), and
in do_journal_get_write_access() we do check to see if the buffers are
present. But if they aren't, we don't return an error; we just fail
request journal write access for the buffer head.
Am I missing something? This patch doesn't feel complete, or the
commit description is very confusing....
- Ted
next prev parent reply other threads:[~2009-08-26 2:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-25 14:22 [PATCH] ext4: Drop mapped buffer_head check during page_mkwrite Aneesh Kumar K.V
2009-08-26 2:24 ` Theodore Tso [this message]
2009-08-26 5:14 ` Aneesh Kumar K.V
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=20090826022445.GA32712@mit.edu \
--to=tytso@mit.edu \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--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.