GEISA Container Format

OCI containers are the de facto standard used by the IT industry to allow Linux containers to be run under a variety of different container environments (e.g. Docker, Podman, RunC, CRun, etc.). The design approach taken in OCI assumes that storage and bandwidth are cheap. With OCI containers, additional layers are created when changes need to be made to dependent file-systems. This approach is not practical for embedded systems.

GEISA containers use the Linux Overlay Filesystem, rather than depending on layering system used within OCI.

During mounting the Linux kernel is able to mount one or more “lower” file systems, as well as an “upper” file system. Lower filesystems are effectively read-only, as writes are made to the upper filesystem. Each additional lower filesystem is layered on top of the one below it, such that the file system available to the container is the union of all of the lower filesystems and the upper filesystem.

Specifically, GEISA containers use a base lower filesystem image and app lower filesystem image. These images are provided as squash filesystem images. The base filesystem image is provided by the platform provider and contains the base libraries provided by the execution environment. This image is shared across applications. Taking this approach ensures that all apps deployed in the environment have direct access to the base libraries within their local environment, without creating unnecessary filesystem duplication in an embedded environment. The app itself is on a second lower filesystem image which contains all of the application-specific libraries and the application executable itself. Finally, the execution environment provides an app instance specific upper filesystem which is persisted across invocations, allowing applications to a place to store working data. This space is subject to quotas / allocations controlled by the management system.

Assume that at a given platform stores the application and base images in a /var/images directory and working space for apps in /var/app. To create the composite mount point required for the container run time for an app, the platform would create a writable filesystem image for the new app, and mount it along with the /images/base.squash and /images/app.squash. On a command line this would look like this: