* Questions about dquota write by writeback in the context of storage shortage
[not found] <CGME20250808050852epcas2p41faca5b3fd8a7bc18cc173ce44650bff@epcas2p4.samsung.com>
@ 2025-08-08 5:08 ` hoyoung seo
0 siblings, 0 replies; only message in thread
From: hoyoung seo @ 2025-08-08 5:08 UTC (permalink / raw)
To: linux-scsi, linux-kernel, alim.akhtar, avri.altman, jejb,
martin.petersen, beanhuo, bvanassche, kwangwon.min, kwmad.kim,
cpgs, h10.kim, linux-fsdevel, hch
Hi,
When the storage usage was full(99%), the following panic_on_warm occurred.
In this case, wb_writeback function used writeback workqeue included WQ_MEM_RECLAIM flag.
And wb_writeback function called f2fs_write_single_data_page for updating dquot(Write checkpoint to reclaim prefree segments)
In this case, dquot_writback_dquots function use events_unbound workqueue.
It is not include WQ_MEM_RECLAIM flag.
So occurred this problem.
First of all, I don't think this situation should be created, but I don't know why it's like this
So I guess quota_release_workfn function should use workqueue with WQ_MEM_RECLAIM flag, but is this the right solution?
workqueue: WQ_MEM_RECLAIM writeback:wb_workfn is flushing !WQ_MEM_RECLAIM events_unbound:quota_release_workfn
Call trace:
check_flush_dependency+0x160/0x16c
__flush_work+0x168/0x738
flush_delayed_work+0x58/0x70
dquot_writeback_dquots+0x90/0x4bc
f2fs_do_quota_sync+0x120/0x284
f2fs_write_checkpoint+0x58c/0xe18
f2fs_gc+0x3e8/0xd78
f2fs_balance_fs+0x204/0x284
f2fs_write_single_data_page+0x700/0xaf0
f2fs_write_data_pages+0xe94/0x15bc
do_writepages+0x170/0x3f8
__writeback_single_inode+0xa0/0x8c4
writeback_sb_inodes+0x2ac/0x708
__writeback_inodes_wb+0xc0/0x118
wb_writeback+0x1f4/0x664
wb_workfn+0x62c/0x900
Thanks.
^ permalink raw reply [flat|nested] only message in thread