From: Ted Ts'o <tytso@mit.edu>
To: Yongqiang Yang <xiaoqiangnk@gmail.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
Curt Wohlgemuth <curtw@google.com>,
linux-ext4@vger.kernel.org, jim@meyering.net, cmm@us.ibm.com,
hughd@google.com
Subject: Re: [PATCH v3] ext4: Don't set PageUptodate in ext4_end_bio()
Date: Tue, 26 Apr 2011 08:19:38 -0400 [thread overview]
Message-ID: <20110426121938.GD9486@thunk.org> (raw)
In-Reply-To: <BANLkTikJjHKchRTt3t2jW+O_1wba9v8jmg@mail.gmail.com>
On Tue, Apr 26, 2011 at 03:41:47PM +0800, Yongqiang Yang wrote:
> This function is only called from write path which flushes pages to
> disk, actually, pages' state have been set right at time when
> write_end() is called. Why did we handle pages' state in this
> function?
This was a bug on my part. A lot of page_io.c was copied from
fs/buffer.c, and then optimized for bulk page writes, instead of
sending down a separate 4k bio write request at a time. I
(incorrectly) copied logic from block_commit_write() into the write
completion callback(). So I agree with Curt that the messing with the
page state should be removed from ext4_end_bio().
As far as messing with the buffer_dirty() logic, it's just wrong to be
clearing the buffer dirty bit at all in the write callback. In the
original codepath, the buffer dirty bit was set by
block_commit_write(), only to be cleared immediately by
__block_write_full_page(). I'm pretty sure the setting and clearing
the buffer dirty bit can be optimized out of fs/ext4/page_io.c
What does bother me a little bit is that we have code that tests
buffer_dirty() in the delalloc logic in fs/ex4/inode.c --- note
ext4_bh_delay_on_unwritten(), and write_cache_pages_da(), where we are
testing the buffer_dirty bit for the pages that hang off of struct
page. The only thing that might bear on this is the
ext4_block_truncate_page(), which does call mark_buffer_dirty() on the
buffer containing the truncation point (which by the way has made me
very worried about the punch code getting very well tested on 1k block
size file systems, since the edge cases when the region to be
truncated are not page-aligned are obviously going to be very hard to
get right).
I *think* we should be nuking the buffer_dirty manipulations in the
delalloc path, but we need to look very closely at that to make sure
there isn't anything going on here...
- Ted
next prev parent reply other threads:[~2011-04-26 12:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-25 20:23 [PATCH v3] ext4: Don't set PageUptodate in ext4_end_bio() Curt Wohlgemuth
2011-04-25 22:40 ` Andreas Dilger
2011-04-25 22:45 ` Curt Wohlgemuth
2011-04-25 23:20 ` Curt Wohlgemuth
2011-04-26 0:58 ` Andreas Dilger
2011-04-26 4:32 ` Curt Wohlgemuth
2011-04-26 6:59 ` Yongqiang Yang
2011-04-26 15:37 ` Curt Wohlgemuth
2011-04-26 15:52 ` Yongqiang Yang
2011-04-26 7:41 ` Yongqiang Yang
2011-04-26 12:19 ` Ted Ts'o [this message]
2011-05-10 17:41 ` Hugh Dickins
2011-05-10 19:17 ` Ted Ts'o
2011-05-10 19:45 ` Hugh Dickins
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=20110426121938.GD9486@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=cmm@us.ibm.com \
--cc=curtw@google.com \
--cc=hughd@google.com \
--cc=jim@meyering.net \
--cc=linux-ext4@vger.kernel.org \
--cc=xiaoqiangnk@gmail.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;
as well as URLs for NNTP newsgroup(s).