[PATCH] fsck: add --workers option to configure worker threads

[Utkal Singh]

Understood. I'll drop this patch and fold the --workers
option into the full MT implementation once the design
is settled. Thanks for the feedback.

Utkal

On Sun, 22 Mar 2026 at 15:18, Gao Xiang <hsiangkao at linux.alibaba.com> wrote:
>
>
>
> 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
> >>
> >
>