docs: add design proposal for EROFS rootfs support#283
Conversation
|
Thank you for your very detailed proposal. I think we can only support EROFS for container images, as the usage of guest images is extremely limited in our design. In typical scenarios, there should only be one guest image globally, which should be pre-deployed on each computing node and shared with all sandboxes through pmem. EROFS almost does not bring any benefits to the guest image, so we can focus on the container image scenario. In fact, we do use EROFS to support container images internally. @charliecgxu @ls-ggg @hlz260 @zhuangel Do you have any suggestions? |
11b7bfb to
22c8994
Compare
This KEP proposes integrating EROFS (Enhanced Read-Only File System) as a container Rootfs artifact support within CubeSandbox. Key features: - Support for EROFS artifacts with LZ4 compression. - Explicit fs_type metadata propagation between CubeMaster, Cubelet, and CubeShim. - Optimization for high-density and high-concurrency AI Agent sandbox scenarios. - Strict scope limitation to container Rootfs (Guest OS remains ext4). Signed-off-by: novahe <heqianfly@gmail.com>
|
I agree with you. Since multiple sandboxes share a single Guest OS rootfs, the gains are pretty minimal, and we'd lose the DAX capability. Let's keep our proposal focused on the container rootfs instead. I've updated the version, PTAL @kinwin-ustc |
Description
This PR introduces a comprehensive design proposal for integrating EROFS (Enhanced Read-Only File System) into the CubeSandbox runtime for container Rootfs artifacts. The goal is to optimize storage efficiency, distribution speed, and cold-start performance for read-only layers.
Key Highlights:
erofs-utilsversioning (>= 1.5.0) and xattr support to preserve OverlayFS metadata (Whiteouts).Note: In this proposal, the Guest OS rootfs remains using the existing ext4 scheme to maintain stability, while workload Rootfs artifacts are extended to support EROFS.
Related Issues
Relates to #274