GSoC 2026: interested in multi-threaded fsck.erofs decompression

[Utkal Singh]

Hi Gao Xiang,

I'm Utkal Singh — I've been sending patches to erofs-utils and the kernel
erofs tree over the past few weeks. You reviewed my h_shared_count
validation patch for fs/erofs/xattr.c (the v2 that switched from division
to multiplication, per your feedback). I also sent the ZSTD decompression
bug series (missing ret = -EIO and unvalidated frame content size), the
deflate buffer overflow cap, fsck xattr verification decoupling, strdup
NULL checks in lib/tar.c, and a few others.

I'm planning to propose the multi-threaded decompression project from the
GSoC 2026 roadmap for my application. After working on the decompression
and fsck code paths, I think I have a reasonable approach in my mind how to
approach this:

Since pclusters are mostly independent units, the natural approach seems to
be a thread pool where worker threads handle decompression of individual
pclusters while the main thread walks the inode tree and coordinates I/O
and output ordering. The tricky parts would be managing output ordering
(files span multiple pclusters), handling shared pclusters correctly, and
making sure the memory footprint stays reasonable with a bounded work
queue. All four algorithms (LZ4, LZMA, DEFLATE, ZSTD) would need to work,
and it should never be slower than the current single-threaded path.

A couple of things I'm not sure about yet:
- Would you prefer pthreads directly, or is there a threading abstraction
you'd want to see in liberofs?
- Should I scope this to just --extract, or would --check parallelism also
be useful?
- Any other design preferences I should keep in mind?

I'm planning to submit my proposal well before the March 31 deadline. If
you have a few minutes to point me in the right direction, that would
really help me write a stronger proposal.

Thanks again for the reviews on my earlier patches — the feedback on the
h_shared_count iteration especially helped me understand the project's code
style better.

Best,
Utkal Singh
https://github.com/Utkal059
singhutkal015 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20260318/c50125a0/attachment.htm>