From: Lukas Czerner <lczerner@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-ext4@vger.kernel.org, jlayton@kernel.org, tytso@mit.edu,
linux-fsdevel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v2 2/3] fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE
Date: Mon, 8 Aug 2022 12:26:05 +0200 [thread overview]
Message-ID: <20220808102605.racoct6amqn55uqc@fedora> (raw)
In-Reply-To: <20220807230810.GF3861211@dread.disaster.area>
On Mon, Aug 08, 2022 at 09:08:10AM +1000, Dave Chinner wrote:
> On Wed, Aug 03, 2022 at 12:53:39PM +0200, Lukas Czerner wrote:
> > Currently the I_DIRTY_TIME will never get set if the inode already has
> > I_DIRTY_INODE with assumption that it supersedes I_DIRTY_TIME. That's
> > true, however ext4 will only update the on-disk inode in
> > ->dirty_inode(), not on actual writeback. As a result if the inode
> > already has I_DIRTY_INODE state by the time we get to
> > __mark_inode_dirty() only with I_DIRTY_TIME, the time was already filled
> > into on-disk inode and will not get updated until the next I_DIRTY_INODE
> > update, which might never come if we crash or get a power failure.
> >
> > The problem can be reproduced on ext4 by running xfstest generic/622
> > with -o iversion mount option.
> >
> > Fix it by allowing I_DIRTY_TIME to be set even if the inode already has
> > I_DIRTY_INODE. Also make sure that the case is properly handled in
> > writeback_single_inode() as well. Additionally changes in
> > xfs_fs_dirty_inode() was made to accommodate for I_DIRTY_TIME in flag.
> >
> > Thanks Jan Kara for suggestions on how to make this work properly.
> >
> > Cc: Dave Chinner <david@fromorbit.com>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Signed-off-by: Lukas Czerner <lczerner@redhat.com>
> > Suggested-by: Jan Kara <jack@suse.cz>
> > ---
> > v2: Reworked according to suggestions from Jan
>
> ....
>
> > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> > index aa977c7ea370..cff05a4771b5 100644
> > --- a/fs/xfs/xfs_super.c
> > +++ b/fs/xfs/xfs_super.c
> > @@ -658,7 +658,8 @@ xfs_fs_dirty_inode(
> >
> > if (!(inode->i_sb->s_flags & SB_LAZYTIME))
> > return;
> > - if (flag != I_DIRTY_SYNC || !(inode->i_state & I_DIRTY_TIME))
> > + if ((flag & ~I_DIRTY_TIME) != I_DIRTY_SYNC ||
> > + !((inode->i_state | flag) & I_DIRTY_TIME))
> > return;
>
> My eyes, they bleed. The dirty time code was already a horrid
> abomination, and this makes it worse.
>
> From looking at the code, I cannot work out what the new semantics
> for I_DIRTY_TIME and I_DIRTY_SYNC are supposed to be, nor can I work
Hi Dave,
please see the other thready for this patch with Eric Biggers, where I
try to explain and give some suggestion to change the doc. Does it make
sense to you, or am I missing something?
https://marc.info/?l=linux-ext4&m=165970194205621&w=2
> out what the condition this is new code is supposed to be doing. I
> *can't verify it is correct* by reading the code.
The ->dirty_inode() needed to be changed to clear I_DIRTY_TIME from
i_state *before* we call ->dirty_inode() to avoid race where we would
lose timestamp update that comes just a little later, after
-dirty_inode() call with I_DRITY_INODE.
But that would break xfs, so I decided to keep the condition and loosen
the requirement so that I_DIRTY_TIME can also be se in 'flag', not just
the i_state. Hence the abomination.
>
> Can you please add a comment here explaining the conditions where we
> don't have to log a new timestamp update?
How about something like this?
Only do the timestamp update if the inode is dirty (I_DIRTY_SYNC) and
has dirty timestamp (I_DIRTY_TIME). I_DIRTY_TIME can be either already
set in i_state, or passed in flags possibly together with I_DIRTY_SYNC.
>
> Also, if "flag" now contains multiple flags, can you rename it
> "flags"?
Sure, I can do that.
Thanks!
-Lukas
>
> Cheers,
>
> Dave.
>
> --
> Dave Chinner
> david@fromorbit.com
>
next prev parent reply other threads:[~2022-08-08 10:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-03 10:53 [PATCH v2 1/3] ext4: don't increase iversion counter for ea_inodes Lukas Czerner
2022-08-03 10:53 ` [PATCH v2 2/3] fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE Lukas Czerner
2022-08-05 8:05 ` Eric Biggers
2022-08-05 12:23 ` Lukas Czerner
2022-08-12 18:20 ` Eric Biggers
2022-08-07 23:08 ` Dave Chinner
2022-08-08 10:26 ` Lukas Czerner [this message]
2022-08-03 10:53 ` [PATCH v3 3/3] ext4: unconditionally enable the i_version counter Lukas Czerner
2022-08-03 13:04 ` Jeff Layton
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=20220808102605.racoct6amqn55uqc@fedora \
--to=lczerner@redhat.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--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.