linux-ext4 - Re: [PATCH] jbd2: Increase IO priority of checkpoint.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f6d49614-bb35-450b-a683-d514b2b52f31@bytedance.com>
Date: Wed, 27 Aug 2025 19:53:52 +0800
From: Julian Sun <sunjunchao@...edance.com>
To: Jan Kara <jack@...e.cz>
Cc: "Ritesh Harjani (IBM)" <ritesh.list@...il.com>,
 linux-ext4@...r.kernel.org, tytso@....edu, jack@...e.com, yi.zhang@...wei.com
Subject: Re: [PATCH] jbd2: Increase IO priority of checkpoint.

在 2025/8/27 19:15, Jan Kara 写道:
> On Wed 27-08-25 12:57:32, Julian Sun wrote:
>> 在 2025/8/27 04:55, Ritesh Harjani (IBM) 写道:
>>> Julian Sun <sunjunchao@...edance.com> writes:
>>>
>>>> In commit 6a3afb6ac6df ("jbd2: increase the journal IO's priority"),
>>>> the priority of IOs initiated by jbd2 has been raised, exempting them
>>>> from WBT throttling.
>>>> Checkpoint is also a crucial operation of jbd2. While no serious issues
>>>> have been observed so far, it should still be reasonable to exempt
>>>> checkpoint from WBT throttling.
>>>>
>>>
>>> Interesting.. I was wondering whether we were able to observe any
>>> throttling for jbd2 log writes or for jbd2 checkpoint?
>>> Maybe It would have been nice, if we had some kind of data for this.
>>
>> Good idea. But AFAICS wbt lacks of such a obversation mechanism now..>
> 
> Well, I guess Ritesh meant some test case which is reproducing the
> situation where jbd2 log writes get stalled.

Ah, thanks for the clarification. It may be a little bit difficult to 
reproduce it manually, I’ll give it a shot but I’m not sure if I can do 
it..>
>>> BTW - does it make sense for fastcommit path too maybe for non-tail
>>> fc write requests? I think it uses ext4_fc_submit_bh().
>>
>> Yeah, I think so.
>> After a rough check of the code, the following code paths may result in high
>> latency or even task hangs:
>>    1. fastcommit io is throttled by wbt or other block layer qos policies.
>>    2. jbd2_fc_wait_bufs() might wait for a long time while
>> JBD2_FAST_COMMIT_ONGOING is set in journal->flags, and then
>> jbd2_journal_commit_transaction() waits for the JBD2_FAST_COMMIT_ONGOING bit
>> for a long time while holding the write lock of j_state_lock.
>>    3. start_this_handle() waits for read lock of j_state_lock which results
>> in high latency or task hang.
>>
>> Hi, Jan, please correct me if I'm missing anything.
> 
> I think you're correct. In fact ext4_fc_commit() does modify current
> process' io priority to match that of jbd2 thread so it would be logical
> to match IO submission flags as well.

Thanks, I will send a patch to improve here.>
> 								Honza


-- 
Julian Sun <sunjunchao@...edance.com>