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)
[x] If the project is accepted, I agree the project will follow the CNCF IP Policy
Trademark and accounts
[x] 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
Application contact emails
Ben Breard - bbreard@redhat.com Mark Russell - mrussell@redhat.com Neil Smith - nesmith@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:
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
Trademark and accounts
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