From: Dave Chinner <david@fromorbit.com>
To: Zhongwei Cai <sunrise_l@sjtu.edu.cn>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca,
linux-ext4@vger.kernel.org, mingkaidong@gmail.com
Subject: Re: [PATCH] ext4: remove unnecessary ext4_inode_datasync_dirty in read path
Date: Wed, 3 Nov 2021 11:28:43 +1100 [thread overview]
Message-ID: <20211103002843.GC418105@dread.disaster.area> (raw)
In-Reply-To: <20211102024258.210439-1-sunrise_l@sjtu.edu.cn>
On Tue, Nov 02, 2021 at 10:42:58AM +0800, Zhongwei Cai wrote:
> ext4_inode_datasync_dirty will call read_lock(&journal->j_state_lock) in
> journal mode, which is unnecessary in read path (As far as I know, the
> IOMAP_F_DIRTY flag set in the if branch is only used in write path,
> making it unnecessary in read path. Please correct me if I'm wrong).
IOMAP_F_DIRTY isn't conditional on the type of lookup being done. If
the inode is dirty in a way that O_DSYNC would require it to be
flushed to make the data stable, iomap should be told that it is
dirty, even on read lookups...
e.g. iomap_swapfile_activate() uses IOMAP_REPORT as the flags for
extent mapping iteration passed to iomap_swapfile_iter(). THis then
checks:
/* No uncommitted metadata or shared blocks. */
if (iomap->flags & IOMAP_F_DIRTY)
return iomap_swapfile_fail(isi, "is not committed");
IOWs, we expect the IOMAP_F_DIRTY flag to be set on all types of
iomap mapping calls if the inode is dirty, not just IOMAP_WRITE
calls.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2021-11-03 0:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-02 2:42 [PATCH] ext4: remove unnecessary ext4_inode_datasync_dirty in read path Zhongwei Cai
2021-11-03 0:28 ` Dave Chinner [this message]
2021-11-04 9:29 ` Zhongwei Cai
2021-11-04 23:22 ` Dave Chinner
2021-11-05 5:28 ` Zhongwei Cai
2021-11-09 4:50 ` Dave Chinner
2021-11-10 8:07 ` Zhongwei Cai
2021-11-11 3:12 ` Dave Chinner
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=20211103002843.GC418105@dread.disaster.area \
--to=david@fromorbit.com \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=mingkaidong@gmail.com \
--cc=sunrise_l@sjtu.edu.cn \
--cc=tytso@mit.edu \
/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.