[PATCH] fsck: add --workers option to configure worker threads
Gao Xiang
hsiangkao at linux.alibaba.com
Sun Mar 22 20:48:37 AEDT 2026
On 2026/3/22 17:31, Utkal Singh wrote:
> Hi Nithurshen,
>
> Thanks for testing the patch and for the detailed feedback.
>
> You're right about the strtoul() wrap-around on 32-bit systems — I'll
> switch to strtol() and add explicit error reporting in v2.
>
> Regarding the design concern: I agree that landing just the CLI
> portion without wiring it to the workqueue may be premature. I'll
> hold off on v2 until we hear from Gao Xiang on whether this should
> wait for the broader multi-threaded fsck design.
This patch is simply not needed as an individual patch.
>
> Thanks,
> Utkal
>
> On Sun, 22 Mar 2026 at 14:27, Nithurshen <nithurshen.dev at gmail.com> wrote:
>
>> As you know, currently decompression process in fsck.erofs is currently
>> strictly single threaded. In fsck/main.c, erofs_verify_inode_data
>> still processes blocks synchronously via a standard while loop.
>> Without wiring this flag to the workqueue engine in lib/workqueue.c,
>> the option doesn't currently change the tool's behavior.
>>
>> And as you know "Multi-threaded Decompression Support in fsck.erofs"
>> is actually an official GSoC 2026 project idea and the project will
>> likely involve a comprehensive design of the parallelized
>> architecture, landing just the --workers CLI portion now might be
>> premature or conflict with the eventual design chosen by the GSoC
>> contributor.
>>
>> I'd suggest reaching out to the mentors on the list to see if they
>> want to hold off on this patch until the GSoC project kicks off.
>> Also, if you do send a v2, switching to strtol() would be safer to
>> avoid potential -1 wrap-around issues on 32-bit systems.
>>
>> Best,
>> Nithurshen
>>
>
More information about the Linux-erofs
mailing list