All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis.henriques@linux.dev>
To: Jan Kara <jack@suse.cz>
Cc: "Luis Henriques (SUSE)" <luis.henriques@linux.dev>,
	 Theodore Ts'o <tytso@mit.edu>,
	 Andreas Dilger <adilger@dilger.ca>,  Jan Kara <jack@suse.com>,
	 linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] jbd2: reset fast commit offset only after fs cleanup is done
Date: Wed, 22 May 2024 14:36:20 +0100	[thread overview]
Message-ID: <87le42dl4b.fsf@brahms.olymp> (raw)
In-Reply-To: <20240522104500.z343a6xqfduuq5i3@quack3> (Jan Kara's message of "Wed, 22 May 2024 12:45:00 +0200")

On Wed 22 May 2024 12:45:00 PM +02, Jan Kara wrote;

> On Tue 21-05-24 16:45:35, Luis Henriques (SUSE) wrote:
>> When doing a journal commit, the fast journal offset (journal->j_fc_off) is
>> set to zero too early in the process.  Since ext4 filesystem calls function
>> jbd2_fc_release_bufs() in its j_fc_cleanup_callback (ext4_fc_cleanup()),
>> that call will be a no-op exactly because the offset is zero.
>> 
>> Move the fast commit offset further down in the journal commit code, until
>> it's mostly done, immediately before clearing the on-going commit flags.
>> 
>> Signed-off-by: Luis Henriques (SUSE) <luis.henriques@linux.dev>
>
> Did you see any particular failure because of this? Because AFAICS the
> buffers cleaned up by jbd2_fc_release_bufs() are only allocated during fast
> commit (from ext4_fc_reserve_space()). And the code in
> jbd2_journal_commit_transaction() is making sure fast commit isn't running
> before we set journal->j_fc_off to 0.

No, I did not see any failure caused by this, this patch is simply based
on my understanding of the code after spending some time reviewing it.

The problem I saw was that jbd2_journal_commit_transaction() will run the
clean-up callbacks, which includes ext4_fc_cleanup().  One of the first
things that this callback will do is to call jbd2_fc_release_bufs().
Because journal->j_fc_off is zero, this call is useless:

	j_fc_off = journal->j_fc_off;

	for (i = j_fc_off - 1; i >= 0; i--) {
		[...]
	}

(It's even a bit odd to start the loop with 'i = -1'...)

So the question is whether this call is actually useful at all.  Maybe the
thing to do is to simply remove the call to jbd2_fc_release_bufs()?  (And
in that case, remove the function too, as this is the only call site.)

Cheers,
-- 
Luis

>
> 								Honza
>
>> ---
>>  fs/jbd2/commit.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
>> index 75ea4e9a5cab..88b834c7c9c9 100644
>> --- a/fs/jbd2/commit.c
>> +++ b/fs/jbd2/commit.c
>> @@ -435,7 +435,6 @@ void jbd2_journal_commit_transaction(journal_t *journal)
>>  			commit_transaction->t_tid);
>>  
>>  	write_lock(&journal->j_state_lock);
>> -	journal->j_fc_off = 0;
>>  	J_ASSERT(commit_transaction->t_state == T_RUNNING);
>>  	commit_transaction->t_state = T_LOCKED;
>>  
>> @@ -1133,6 +1132,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
>>  		  journal->j_commit_sequence, journal->j_tail_sequence);
>>  
>>  	write_lock(&journal->j_state_lock);
>> +	journal->j_fc_off = 0;
>>  	journal->j_flags &= ~JBD2_FULL_COMMIT_ONGOING;
>>  	journal->j_flags &= ~JBD2_FAST_COMMIT_ONGOING;
>>  	spin_lock(&journal->j_list_lock);
>> 
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

  reply	other threads:[~2024-05-22 13:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21 15:45 [RFC PATCH 0/2] ext4: two small fast commit fixes Luis Henriques (SUSE)
2024-05-21 15:45 ` [RFC PATCH 1/2] ext4: fix fast commit inode enqueueing during a full journal commit Luis Henriques (SUSE)
2024-05-22 10:35   ` Jan Kara
2024-05-22 13:21     ` Luis Henriques
2024-05-21 15:45 ` [RFC PATCH 2/2] jbd2: reset fast commit offset only after fs cleanup is done Luis Henriques (SUSE)
2024-05-22 10:45   ` Jan Kara
2024-05-22 13:36     ` Luis Henriques [this message]
2024-05-23  7:44       ` Jan Kara
2024-05-23  8:52         ` Luis Henriques

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=87le42dl4b.fsf@brahms.olymp \
    --to=luis.henriques@linux.dev \
    --cc=adilger@dilger.ca \
    --cc=jack@suse.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.