[GSoC 2026] Multi-threaded decompression for fsck.erofs — design question on z_erofs_decompress() parallelism

[Deepak Pathik]

Hi,

I'm Deepak Pathik, a second-year B.Tech student applying for the GSoC 2026
project on multi-threaded decompression support in fsck.erofs.

While reading through the source, I traced the decompression path in
erofs_verify_inode_data() and noticed that z_erofs_decompress() operates on
a locally scoped struct z_erofs_decompress_req with its own input and
output buffers — no shared mutable state between calls. My plan is to wire
the existing erofs_workqueue (already used in lib/compress.c for
mkfs.erofs) into the fsck extraction path at the pcluster level, with
pwrite() for position-based output writes to avoid ordering locks.

One thing I wanted to confirm before finalizing my proposal: for
LZMA-compressed images, are pclusters in fsck.erofs always fixed-size and
independently decompressible at the userspace level, or are there cases
where a pcluster depends on the state left by a previous one? I want to
make sure I'm not understating the LZMA case in my design.

I've drafted a proposal and would be happy to share it for early feedback
if that's useful.

Thanks,
Deepak Pathik
https://github.com/deepakpathik
deepakpathik2005 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20260329/b7195cbe/attachment.htm>