On Fri 17-01-25 10:58:42, Zhang Yi wrote: > On 2025/1/17 2:02, Jan Kara wrote: > > Some users are reporting journal replay takes a long time when there is > > excessive number of revoke blocks in the journal. Reported times are > > like: > > > > 1048576 records - 95 seconds > > 2097152 records - 580 seconds > > > > The problem is that hash chains in the revoke table gets excessively > > long in these cases. Fix the problem by sizing the revoke table > > appropriately before the revoke pass. > > > > Thanks to Alexey Zhuravlev <azhuravlev@xxxxxxx> for benchmarking the patch with > > large numbers of revoke blocks [1]. > > > > [1] https://lore.kernel.org/all/20250113183107.7bfef7b6@xxxxxxxxxxxxxx > > > > Signed-off-by: Jan Kara <jack@xxxxxxx> > > Hi, Jan, > > This overall patch looks good to me; however, it appears to be not > based on the latested version of the upstream kernel, and I have one > minor suggestion below. OK, will do. > > @@ -874,14 +905,16 @@ static int do_one_pass(journal_t *journal, > > need_check_commit_time = true; > > } > > > > - /* If we aren't in the REVOKE pass, then we can > > - * just skip over this block. */ > > - if (pass != PASS_REVOKE) { > > + /* > > + * If we aren't in the SCAN or REVOKE pass, then we can > > + * just skip over this block. > > + */ > > + if (pass != PASS_REVOKE && pass != PASS_SCAN) { > > brelse(bh); > > continue; > > } > > How about move this code snippets to the beginning of the > JBD2_REVOKE_BLOCK branch case? I guess a good idea after the change. Thanks! Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
