Skip to content

Unified storage #20

@cgwalters

Description

@cgwalters

Status quo

See the filesystem docs.

Goals

Proposal 1 (Phase 0): optionally pull first into c/storage

User experience

  • For the upgrade/switch path, we will check if the image is already present in the bootc-owned container storage. If so, we will use the unified path. To onboard to this feature, use the command: bootc image set-unified - this just re-pulls (from the original source, usually registry) the currently booted container image but this time into the bootc owned storage.

  • For the install path, a new flag such as --experimental-unified-storage will enable the feature during installation.

This will start out as an opt-in experimental mode. We initially considered adding a configuration file or option to enable the mode (possibly within the origin file), but decided against it for now. Instead, we are opting for automatic detection during switch/upgrade and a flag for installation. This approach will be revisited once the feature becomes more robust and stable.

Basically our initial fetch we pull the base OS image via just directly doing a podman pull or skopeo copy the same way we pull LBIs.

From there, we do a reflink/hardlink copy into the ostree store (i.e. This would duplicate metadata, but not data on disk. Reflinks should always work. If we have to do hardlinks it could potentially confuse the st_nlink count if any LBIs happen to share layers. But that seems unlikely.

We'll also need to teach the garbage collection code about this.

Incremental transition

Probably the best way to do this is to change things so on upgrade, we only pull layers into the LBI storage if they didn't already exist in the ostree store or so.

More info

Today this project uses ostree-containers for the base image.

Much more recently, we landed logically bound app images which ended up requiring a bootc-owned containers/storage instance.

This left us in a confusing situation where we have two image storage backends used by bootc - one for the booted host, and one for LBIs.

The code they don't share is mostly containers/storage.

This issue tracks unification: Having bootc leverage more of containers/storage (which is going to likely require containers/storage improvements.

This issue also intersects #1016 in that we would need to get progress out of podman pulls

Note: I did a draft PR for this a while ago #215

Update 20250632: See also #1190 for transitioning to a "native composefs" storage.

Random notes

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/unified-storageThis issue relates to unified storage https://github.com/bootc-dev/bootc/issues/20enhancementNew feature or requesttriagedThis looks like a valid issue

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions