Storage

Namespace offers two types of storage to users:

• Container registry: an integrated private container registry to build and deploy container images to Namespace.
• Cache volumes: fast local storage designed for caching purposes.

Cache volumes

Cache volumes can be attached (i.e., mounted into a user-specified directory) to an instance at creation time.

They act as regular disks with the following properties:

• They're backed by local NVME storage. You can expect high performance.
• A cache volume is formatted as a regular Linux filesystem (e.g., ext4), so you can expect them to support any use-case you have that Linux supports.

Namespace adopts a unique strategy to support multi-writer scenarios, typical to Continuous Integration (i.e. multiple runners want to read and write to the cache).

When requesting a cache volume, Namespace attaches a "fork" of the previous cache volume version (all but the first one, which starts empty). Each compute instance gets its own private copy of the cache volume, as it existed at the time of the last cache commit.

As an instance completes, its copy (fork) becomes the new parent for future forks.

Naming

Unique tags govern access to cache volumes - usable by any instance. Each tag maintains a list of cache volume versions. When creating new compute instances, Namespace attempts to attach as recent of a cache volume version as possible to that new instance.

Lifecycle

At any point in time, multiple versions of the cache volume may be used by different compute instances.

The first request creates the first version, used as the parent of subsequent forks until a new parent version is committed.

Version commits follow a "last write" model: whenever a compute instance terminates cleanly (e.g., it's a job and exits with exit code 0), cache volumes attached to that instance have a new parent committed: the final flushed volume of the exiting instance.

Whenever a compute instance fails, Namespace abandons its cache volume versions.

Guarantees and non-guarantees

To ensure that we consistently offer high-performance cache volumes, with close to zero impact on startup latency, Namespace trade-offs on cache volume hit ratio.

It maximizes the probability that an instance can obtain a fork of the previous version of a cache volume, but it does not guarantee it.

Thus users should not build applications assuming that the contents of a cache volume match exactly the last committed version.