<div dir="ltr"> Dear Yifan, Chunhai, and Gao Xiang,<br><br>I am Yash Gupta, a second-year MCA student at Chandigarh University, India (IST, UTC+5:30). I am writing to introduce myself ahead of submitting my GSoC 2026 proposal for the "Multi-threaded Decompression Support in fsck.erofs" project.<br><br>I have studied the three problems documented openly in the erofs-utils README — single-threaded extraction, slow fragment decompression, and missing xattr/ACL restoration — and my proposal addresses all three directly.<br><br>Preparation I have done so far:<br><br>- Built erofs-utils from source on Fedora 41 and Debian 13<br>- Profiled fsck.erofs --extract on sample images using perf and confirmed the single-threaded CPU bottleneck firsthand<br>- Traced the pcluster decompression call path end-to-end through fsck/ and lib/<br>- Reviewed the mkfs.erofs thread-pool implementation as a reference for pool design<br>- Read the containerd EROFS snapshotter documentation to understand how EROFS layer blobs are consumed downstream<br>- Subscribed to <a href="mailto:linux-erofs@lists.ozlabs.org">linux-erofs@lists.ozlabs.org</a> and reviewed the last three months of patches, including commit 2ce4b18 (xattr crash fix in the rebuild path)<br><br>My proposed technical approach:<br><br>- A fixed-size pthreads pool (default: nproc, overridable via -j N) with an MPMC work queue<br>- Pre-allocated, non-overlapping output buffers per inode — no locks needed at write time, zero coordination between worker threads during decompression<br>- A reader-writer-locked hash-map cache keyed by pcluster disk block address to eliminate redundant fragment re-decompression<br>- xattr and ACL restoration via lsetxattr(), built on the stabilized 2ce4b18 base, covering SELinux labels, file capabilities, and POSIX ACL round-trips<br>- TSAN validation on every patch before sending upstream<br><br>I have practical experience with POSIX pthreads, producer-consumer queues, and reader-writer locks from coursework and personal projects. I am familiar with git format-patch, git send-email, Linux kernel coding style, and <a href="http://checkpatch.pl">checkpatch.pl</a>.<br><br>I plan to post baseline benchmark numbers to the mailing list during the community bonding period before writing any code, and to send incremental patch series for review throughout the summer rather than a single large batch at the end.<br><br>My proposal draft is attached. I would greatly appreciate any early feedback — particularly on the thread-pool design, the fragment cache approach, and whether the 12-week timeline is realistic from your perspective.<br><br>Thank you for your time and for maintaining such a well-documented project.<br><br>Best regards,<br>Yash Gupta<br>MCA · Chandigarh University · India<br><a href="http://github.com/developer-yashgupta">github.com/developer-yashgupta</a><br><a href="http://linkedin.com/in/developer-yash">linkedin.com/in/developer-yash</a><br><a href="mailto:yashgupta9437@gmail.com">yashgupta9437@gmail.com</a><br>IST (UTC +5:30)</div>