<div dir="ltr">Hi Nithurshen,<br><br>Thanks for testing the patch and for the detailed feedback.<br><br>You're right about the strtoul() wrap-around on 32-bit systems — I'll<br>switch to strtol() and add explicit error reporting in v2.<br><br>Regarding the design concern: I agree that landing just the CLI<br>portion without wiring it to the workqueue may be premature. I'll<br>hold off on v2 until we hear from Gao Xiang on whether this should<br>wait for the broader multi-threaded fsck design.<br><br>Thanks,<br>Utkal</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, 22 Mar 2026 at 14:27, Nithurshen <<a href="mailto:nithurshen.dev@gmail.com">nithurshen.dev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As you know, currently decompression process in fsck.erofs is currently<br>
strictly single threaded. In fsck/main.c, erofs_verify_inode_data<br>
still processes blocks synchronously via a standard while loop.<br>
Without wiring this flag to the workqueue engine in lib/workqueue.c,<br>
the option doesn't currently change the tool's behavior.<br>
<br>
And as you know "Multi-threaded Decompression Support in fsck.erofs"<br>
is actually an official GSoC 2026 project idea and the project will<br>
likely involve a comprehensive design of the parallelized<br>
architecture, landing just the --workers CLI portion now might be<br>
premature or conflict with the eventual design chosen by the GSoC<br>
contributor.<br>
<br>
I'd suggest reaching out to the mentors on the list to see if they<br>
want to hold off on this patch until the GSoC project kicks off.<br>
Also, if you do send a v2, switching to strtol() would be safer to<br>
avoid potential -1 wrap-around issues on 32-bit systems.<br>
<br>
Best,<br>
Nithurshen<br>
</blockquote></div>