<div dir="ltr">Hi,<br><br>I'm Deepak Pathik, a second-year B.Tech student applying for the GSoC 2026 project on multi-threaded decompression support in fsck.erofs.<br><br>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.<br><br>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.<br><br>I've drafted a proposal and would be happy to share it for early feedback if that's useful.<br><br>Thanks,<br>Deepak Pathik<br><a href="https://github.com/deepakpathik">https://github.com/deepakpathik</a><br><a href="mailto:deepakpathik2005@gmail.com">deepakpathik2005@gmail.com</a><br></div>