Handling dynamic size for /

[cgwalters]

Copying this question from elsewhere, so it's answered in a place indexable by search and findable by others here:

I'm an operator looking at making bootc images, and some of the containers may be much larger than others, and other teams may be building them. I already have separate data partitions for my databases/VMs. If I didn't provision enough space in /, can bootc split its storage across another filesystem?

[cgwalters]

A: No, we don't support splitting the OS content across separate filesystem today. It would be possible in theory but would greatly complicate many aspects of the underlying storage.

Instead, what I suggest is to use some form of dynamic storage, such as LVM, btrfs, Stratis, etc. With all of these types of systems, it's possible to dynamically expand filesystems on demand.

Let's say you're in a situation where you have a system deployed with a 20G /, and you want to add a large set of agent containers or large data as part of the bootc base image and you need an additional 5G.

Today bootc does not perform any filesystem space checks before fetching the image - we could do this, although there's some complications because we deduplicate shared content dynamically and that space check would necessarily need to be conservative today as we don't know the digest for shared objects (zstd:chunked would help with this although I would like to index by fsverity, that's its own side debate).

Anyways but if you're using LVM/btrfs or equivalent, then my recommendation is to track the two key pieces of data:

• Size of your container images
• Size of / for extant deployed systems

If the size of A+B for images would exceed /, then use dynamic reconfiguration (e.g. a dynamic agent container, ansible, just raw ssh, whatever) to expand / before initiating bootc upgrade on the client systems.