All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Czerner <lczerner@redhat.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-ext4@vger.kernel.org, jlayton@kernel.org, tytso@mit.edu,
	linux-fsdevel@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
	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: Fri, 5 Aug 2022 14:23:06 +0200	[thread overview]
Message-ID: <20220805122306.anavrrmt6lqwd2yt@fedora> (raw)
In-Reply-To: <YuzPWfCuVNkmar2n@sol.localdomain>

On Fri, Aug 05, 2022 at 01:05:45AM -0700, Eric Biggers wrote:
> On Wed, Aug 03, 2022 at 12:53:39PM +0200, Lukas Czerner wrote:
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 9ad5e3520fae..2243797badf2 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -2245,9 +2245,9 @@ static inline void kiocb_clone(struct kiocb *kiocb, struct kiocb *kiocb_src,
> >   *			The inode itself only has dirty timestamps, and the
> >   *			lazytime mount option is enabled.  We keep track of this
> >   *			separately from I_DIRTY_SYNC in order to implement
> >   *			lazytime.  This gets cleared if I_DIRTY_INODE
> > - *			(I_DIRTY_SYNC and/or I_DIRTY_DATASYNC) gets set.  I.e.
> > - *			either I_DIRTY_TIME *or* I_DIRTY_INODE can be set in
> > - *			i_state, but not both.  I_DIRTY_PAGES may still be set.
> > + *			(I_DIRTY_SYNC and/or I_DIRTY_DATASYNC) gets set. But
> > + *			I_DIRTY_TIME can still be set if I_DIRTY_SYNC is already
> > + *			in place.
> 
> I'm still having a hard time understanding the new semantics.  The first
> sentence above needs to be updated since I_DIRTY_TIME no longer means "the inode
> itself only has dirty timestamps", right?

The problem is that it was always assumed that I_DIRTY_INODE superseeds
I_DIRTY_TIME and so it would get cleared in __mark_inode_dirty() when we
have I_DIRTY_INODE. That's true, we call sb->s_op->dirty_inode(), the
time update gets pushed into on-disk inode structure, I_DIRTY_TIME
cleared and it will get queued for writeback.

Any subsequent dirtying with I_DIRTY_TIME gets ignored simply because
I_DIRTY_INODE is already set in i_state. But in ext4 this time update
will never get pushed into on disk inode and there is no I_DIRTY_TIME so
once the writeback is done we've lost all those I_DIRTY_TIME updates in
between even if there was a sync.

Now, we still clear I_DIRTY_TIME when we get I_DIRTY_INODE, but any
subsequent I_DIRTY_TIME only updates won't be ignored and we set it into
i_state. After the writeback is done it'll be moved to b_dirty_time
list.

So I am not sure how would you like it to be re-worded, simply removing
the 'only' would be ok?

> 
> Also, have you checked all the places that I_DIRTY_TIME is used and verified
> they do the right thing now?  What about inode_is_dirtytime_only()?

Yes, that's fine, despite the slightly misleading name ;)

> 
> Also what is the precise meaning of the flags argument to ->dirty_inode now?
> 
> 	sb->s_op->dirty_inode(inode,
> 			flags & (I_DIRTY_INODE | I_DIRTY_TIME));
> 
> Note that dirty_inode is documented in Documentation/filesystems/vfs.rst.

Don't know. It alredy don't mention I_DIRTY_SYNC that can be there as
well. Additionaly it can have I_DIRTY_TIME to inform the fs we have a
dirty timestamp as well (in case of lazytime).

Perhaps we can add:

If the inode has dirty timestamp and lazytime is enabled I_DIRTY_TIME
will be set in the flags.

-Lukas

> 
> - Eric
> 


  reply	other threads:[~2022-08-05 12:23 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 [this message]
2022-08-12 18:20       ` Eric Biggers
2022-08-07 23:08   ` Dave Chinner
2022-08-08 10:26     ` Lukas Czerner
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=20220805122306.anavrrmt6lqwd2yt@fedora \
    --to=lczerner@redhat.com \
    --cc=david@fromorbit.com \
    --cc=ebiggers@kernel.org \
    --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.