From: Luis Henriques <luis.henriques@linux.dev>
To: Jan Kara <jack@suse.cz>
Cc: Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger@dilger.ca>,
Harshad Shirwadkar <harshadshirwadkar@gmail.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ext4: fix fast commit inode enqueueing during a full journal commit
Date: Tue, 28 May 2024 16:50:46 +0100 [thread overview]
Message-ID: <87h6eirl49.fsf@brahms.olymp> (raw)
In-Reply-To: <20240528105203.2q4gxqz6amgvud4l@quack3> (Jan Kara's message of "Tue, 28 May 2024 12:52:03 +0200")
On Tue 28 May 2024 12:52:03 PM +02, Jan Kara wrote;
> On Tue 28-05-24 12:36:02, Jan Kara wrote:
>> On Mon 27-05-24 16:48:24, Luis Henriques wrote:
>> > On Mon 27 May 2024 09:29:40 AM +01, Luis Henriques wrote;
>> > >>> + /*
>> > >>> + * Used to flag an inode as part of the next fast commit; will be
>> > >>> + * reset during fast commit clean-up
>> > >>> + */
>> > >>> + tid_t i_fc_next;
>> > >>> +
>> > >>
>> > >> Do we really need new tid in the inode? I'd be kind of hoping we could use
>> > >> EXT4_I(inode)->i_sync_tid for this - I can see we even already set it in
>> > >> ext4_fc_track_template() and used for similar comparisons in fast commit
>> > >> code.
>> > >
>> > > Ah, true. It looks like it could be used indeed. We'll still need a flag
>> > > here, but a simple bool should be enough for that.
>> >
>> > After looking again at the code, I'm not 100% sure that this is actually
>> > doable. For example, if I replace the above by
>> >
>> > bool i_fc_next;
>> >
>> > and set to to 'true' below:
>
> Forgot to comment on this one: I don't think you even need 'bool i_fc_next'
> - simply whenever i_sync_tid is greater than committing transaction's tid,
> you move the inode to FC_Q_STAGING list in ext4_fc_cleanup().
Yeah, I got that from your other comment in the previous email. And that
means the actual fix will be a pretty small patch (almost a one-liner).
I'm running some more tests on v3, I'll probably send it later today or
tomorrow. Thanks a lot for your review (and patience), Jan.
Cheers,
--
Luís
next prev parent reply other threads:[~2024-05-28 15:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 11:16 [PATCH v2] ext4: fix fast commit inode enqueueing during a full journal commit Luis Henriques (SUSE)
2024-05-24 16:22 ` Jan Kara
2024-05-27 8:29 ` Luis Henriques
2024-05-27 15:48 ` Luis Henriques
2024-05-28 10:36 ` Jan Kara
2024-05-28 10:52 ` Jan Kara
2024-05-28 15:50 ` Luis Henriques [this message]
2024-05-29 0:01 ` harshad shirwadkar
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=87h6eirl49.fsf@brahms.olymp \
--to=luis.henriques@linux.dev \
--cc=adilger@dilger.ca \
--cc=harshadshirwadkar@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@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.