[Sandbox] composefs

[marrusl]

Application contact emails

Ben Breard - bbreard@redhat.com
Alex Larsson - alexl@redhat.com
Mark Russell - mrussell@redhat.com
Giuseppe Scrivano - gscrivan@redhat.com
Neil Smith - nesmith@redhat.com
Preethi Thomas - pthomas@redhat.com

Project Summary

The composefs project combines several underlying Linux kernel features to provide a very flexible mechanism that supports read-only mountable filesystem trees, stacking on top of an underlying "lower" Linux filesystem.

Project Description

The composefs project combines several underlying Linux features to provide a very flexible mechanism to support read-only mountable filesystem trees, stacking on top of an underlying "lower" Linux filesystem. It is particularly useful for mounting container images, but has a number of other applications.

The key technologies composefs uses are:

• overlayfs as the kernel interface
• EROFS for a mountable metadata tree
• fs-verity (optional) from the lower filesystem

The manner in which these technologies are combined is important. First, to emphasize: composefs does not store any persistent data itself. The underlying metadata and data files must be stored in a valid "lower" Linux filesystem. Usually on most systems, this will be a traditional writable persistent Linux filesystem such as ext4, xfs, btrfs etc.

The "tagline" for this project is "The reliability of disk images, the flexibility of files", and is worth explaining a bit more. Disk images have a lot of desirable properties in contrast to other formats such as tar and zip: they're efficiently kernel mountable and are very explicit about all details of their layout. There are well known tools such as dm-verity which can apply to disk images for robust security. However, disk images have well known drawbacks such as commonly duplicating storage space on disk, can be difficult to incrementally update, and are generally inflexible.

Composefs aims to provide a similarly high level of reliablility, security, and Linux kernel integration; but with the flexibility of files for content - avoiding doubling disk usage, worrying about partition tables, etc.

Org repo URL (provide if all repos under the org are in scope of the application)

N/A

Project repo URL in scope of application

https://github.com/containers/composefs

Additional repos in scope of the application

No response

Website URL

https://github.com/containers/composefs

Roadmap

https://github.com/containers/composefs/milestones

Roadmap context

N/A

Contributing Guide

https://github.com/containers/composefs/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

The containers community currently has its own CoC. If accepted, it would switch to the CNCF CoC https://github.com/containers/common/blob/main/CODE-OF-CONDUCT.md

Adopters

No response

Contributing or Sponsoring Org

www.redhat.com, fedoraproject.org

Maintainers file

https://github.com/containers/composefs/blob/main/MAINTAINERS.md

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

While composefs was originally developed to advance the container use case, it has already demonstrated that it can advance immutability down to the filesystem layer with its integration into the bootc project.

Composefs has clear applicability to many cloud-native tools and despite being relatively new, it has already drawn interest from other projects. Being part of the CNCF would make it easier for these projects to incorporate Composefs. We chose the CNCF because of the alignment with container technology and the principles of immutable infrastructure and it affirms our intent as a project to expand the community.

Benefit to the Landscape

Composefs can benefit users of all container engines--inside CNCF and not. When using a composefs backing store, if a file has the same content across many container images, it is stored only once--even if the paths and metadata differ between logical copies in different container images. This backing store is also shared with the page cache which should improve startup performance on hosts running many containers that share content.

Faster, denser, more tamper resistant container storage should be of broad interest--particularly in edge scenarios where small differences in startup time can be crucial, and where storage and network usage can add up quickly.

Cloud Native 'Fit'

As noted, composefs enables and enhances immutability at both the container engine and operating system level, and is helping power user space innovation that enables and encourages declarative infrastructure.

In detail, composefs is the lower level integration component needed for bootc to use as its root filesystem. It is also needed to bring fs-verity integrity checks to bootc.

Cloud Native 'Integration'

Bootc uses composefs as its backend. However, the UAPI group, which is a community of image-based userspace maintainers, also leverages composefs. We feel that composefs is an excellent bridge between the cloud native world and the user-space Linux community – two different (and complementary) approaches sharing the lower level filesystem integration.

Cloud Native Overlap

None that we are aware of.

Similar projects

Containerd image store

Landscape

No.

Business Product or Service to Project separation

Composefs is a lower-level component that will not be a standalone product from Red Hat. Rather it’s a technology that will be a feature of other products. The current implementation already meets our product needs, and as such we expect future goals to be driven by the community.

Project Domain Technical Review

Not yet. We plan to present to TAG-Storage in the future.

CNCF Contacts

Karena Angell, Emily Fox, Josh Berkus
Staff: Jorge Castro

Additional information

No response

[mrbobbytables]

For the purposes of review, this will be evaluated as a group including: #308 #309 #310 #311