From: Kazuya Mio <k-mio@sx.jp.nec.com>
To: Jan Kara <jack@suse.cz>
Cc: ext4 <linux-ext4@vger.kernel.org>, Andreas Dilger <adilger@dilger.ca>
Subject: Re: [PATCH 2/2] ext3: Don't update ctime in ext3_splice_branch()
Date: Wed, 08 Feb 2012 17:36:45 +0900 [thread overview]
Message-ID: <4F32341D.6080803@sx.jp.nec.com> (raw)
In-Reply-To: <20120201104633.GA16714@quack.suse.cz>
2012/02/01 19:46, Jan Kara wrote:
> On Wed 01-02-12 16:56:17, Kazuya Mio wrote:
>> 2012/01/31 2:52, Jan Kara wrote:
>>> Thanks for the patches. This is true for ordinary writes but not true
>>> when you write via mmap. We call file_update_time() during page fault so
>>> ctime won't be completely wrong but still we should update it after block
>>> is allocated during writeback to reflect that new block is allocated to
>>> the inode.
>>
>> Should we update ctime whenever a block is allocated?
> Since ctime should be updated whenever inode is changed, and allocating
> block updates i_blocks (via dquot_alloc_block()), we should update ctime.
>
>> If so, ordinary write in ext4 with indirect block mapping has the same problem
>> due to the following patch, right?
>> http://marc.info/?l=linux-ext4&m=124505184027078&w=4
> It's kind of the same problem. But things are more complicated by the
> fact that ext4 also does delayed allocation so, as changelog of the patch
> you reference says, it's kind of unexpected from users to see ctime
> suddently update when VM decides to do writeout triggering block
> allocation. I'd think updating ctime is a correct (although unexpected)
> thing to do but I can understand Ted's position as well and he's ext4
> maintainer :).
I see. But I think we don't need to update ctime every time at this point.
ext3 doesn't support nanosecond timestamp, so it is wasteful to update ctime
whenever we allocate one block. How about the following patch?
http://patchwork.ozlabs.org/patch/140073/
The result of my measurement shows that the above patch can reduce the number of
calling ext3_mark_inode_dirty() almost the same as the previous one.
Regards,
Kazuya Mio
prev parent reply other threads:[~2012-02-08 8:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 8:41 [PATCH 2/2] ext3: Don't update ctime in ext3_splice_branch() Kazuya Mio
2012-01-30 17:52 ` Jan Kara
2012-02-01 7:56 ` Kazuya Mio
2012-02-01 10:46 ` Jan Kara
2012-02-08 8:36 ` Kazuya Mio [this message]
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=4F32341D.6080803@sx.jp.nec.com \
--to=k-mio@sx.jp.nec.com \
--cc=adilger@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
/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.