On 2023/6/9 20:03, Ariel Miculas (amiculas) wrote: ...
But aside from the infrastructure discussion: This is yet another filesystem for solving the container image problem in the kernel with the addition of yet another filesystem. We just went through this excercise with another filesystem. So I'd expect some reluctance here. Tbh, the container world keeps sending us filesystems at an alarming rate. That's two within a few months and that leaves a rather disorganized impression.
Just a head up. Since Rust kernel infrastructure is too premature, it's impossible to handle page cache / iomap and many useful stuffs. In the long term, at least (someday) after Rust infrastructure is mature, I will implement EROFS ino Rust as a try as well. As for chunk CDC, I don't see it's hard (since we already have some CDC approach since Linux v6.1) but as an effective disk filesystem for performance, EROFS on-disk data is all block-aligned to match storage and page cache alignment. If it's really needed, I could update a more complete (but ineffective and slow) index version to implement unaligned extents (both for decoded and encoded sides). Yet I really think the main purpose of a kernel filesystem is to make full use of kernel infrastructure for performance (like page cache handling) otherwise a FUSE approach is enough. Finally, as for OCI container image stuffs, I'd like to avoid saying this topic anymore on the list (too tired about this). I've seen _three_ in-kernel approaches already before this one and I tend to avoid listing the complete names (including FUSE alternatives) here. I really suggest if you guys could sit down and plan at least a complete OCI standard for the next image format (even you don't want to reuse any exist filesystem for whatever reasons). Thanks, Gao Xiang
