Dreamacro：fsck 复用解析原语并作为独立模块推进
Dreamacro 要求 erofs-rs fsck 尽量复用 superblock、inode、dirent、xattr 和解压路径，缺少暴露能力时重构共享代码；建议 fsck 独立模块、库提供低层与高层 API、CLI 构建在高层 API 上，并认可按当前范围推进 phase 1。
作者原文@DreamacroThanks for the detailed proposal. It looks good to me overall. My main concern is code reuse. The fsck module should reuse the existing parsing primitives (superblock, inode, dirent, xattr, and the decompression paths) as much as possible, and it shouldn't duplicate their logic. If something you need isn't exposed or doesn't fit, I'd rather refactor the existing code so both sides can share it than keep a second implementation that drifts out of sync.
On the design question: I'd go with option 1, a separate module. Reading and verification have different goals. A reader often only needs the superblock or a single file, while verification has to walk every entry. Adding a "continue on error" mode to the existing traversal would make the read path more complex for a use case it doesn't serve. A standalone module that builds on the shared primitives and collects findings seems like a cleaner split.
On your questions:
- Both. The library is the core, and the CLI is how we dogfood it. If using our own library feels awkward, we can't expect users to like it. Ideally the library exposes some low-level APIs for fine-grained control, plus a convenient high-level abstraction for the common case. The CLI should be built on that high-level API.
- I don't have a strong preference. Anything that fits idiomatic Rust naming is fine.
- Phase 1 as scoped sounds reasonable to me.
- Most of the
build/work has already landed, so there's no need to wait. Feel free to start, and modify things there if you need to.Looking forward to the PR.