linux-kernel - Re: [PATCH] xfs: don't allow log recover IO to be throttled

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: <20250309124133.1453369-1-alexjlzheng@tencent.com>
Date: Sun,  9 Mar 2025 20:41:33 +0800
From: Jinliang Zheng <alexjlzheng@...il.com>
To: david@...morbit.com
Cc: alexjlzheng@...il.com,
	alexjlzheng@...cent.com,
	cem@...nel.org,
	dchinner@...hat.com,
	djwong@...nel.org,
	linux-kernel@...r.kernel.org,
	linux-xfs@...r.kernel.org
Subject: Re: [PATCH] xfs: don't allow log recover IO to be throttled

On Tue, 4 Mar 2025 07:45:44 +1100, Dave Chinner wrote:
> On Mon, Mar 03, 2025 at 07:23:01PM +0800, Jinliang Zheng wrote:
> > When recovering a large filesystem, avoid log recover IO being
> > throttled by rq_qos_throttle().
> 
> Why?
> 
> The only writes to the journal during recovery are to clear stale
> blocks - it's only a very small part of the IO that journal recovery
> typically does. What problem happens when these writes are
> throttled?

Sorry for the late reply, I was struggling with my work. :-(

Recently, we encountered the problem of xfs log IO being throttled in
the Linux distribution version maintained by ourselves. To be more
precise, it was indirectly throttled by the IO issued by the LVM layer.
For details, see [1] please.

After this problem was solved, we naturally checked other related log
IO paths, hoping that they would not be throttled by wbt_wait(), that
is, we hoped that they would be marked with REQ_SYNC | REQ_IDLE.

For log recover IO, in the LVM scenario, we are not sure whether it
will be affected by IO on other LVs on the same PV. In addition, we
did not find any obvious side effects of this patch. An ounce of
prevention is worth a pound of cure, and we think it is more
appropriate to add REQ_IDLE here.

Of course, if there is really a reason not to consider being throttled,
please forgive me for disturbing you.

[1] https://lore.kernel.org/linux-xfs/20250220112014.3209940-1-alexjlzheng@tencent.com/

Thank you very much. :)
Jinliang Zheng

> 
> -Dave.
> -- 
> Dave Chinner
> david@...morbit.com