Container cold start is often described as a bandwidth problem. A runtime pulls image layers, unpacks them, mounts a filesystem, and starts a process. The paper’s trace study gives a more useful denominator: image pulling accounted for 76% of startup time, while the launched containers read only 6.4% of their image data. Transferring every byte is wasteful, but delaying transfer moves work into the launch-critical filesystem path.
Existing lazy image systems interpose a userspace daemon through FUSE. They avoid the full download, yet a path walk can cross the kernel boundary for every component and a cached payload may still pass through userspace. Background prefetch can hide future misses, but it can also compete with the foreground launch for network and storage bandwidth. CoFS treats those costs as properties of the representation, not unavoidable consequences of lazy loading.
The key restriction is that a container image is immutable after construction. CoFS spends computation at image-build time to compile that fixed namespace into direct indexes. It then lets the host filesystem store downloaded ranges as sparse files, so subsequent reads use the kernel’s ordinary cache and I/O path. This is a narrower design than a general writable filesystem, and that narrowness creates the performance opportunity.
An immutable namespace can be compiled
A conventional filesystem lookup searches directory entries and follows one name component at a time. FUSE adds request serialization, context switches, and daemon scheduling to that path. CoFS constructs a minimal perfect hash function (MPHF) over the known names in each directory when the image is built. A successful hash yields a dense metadata-array position without collisions among the stored keys.
The image contains the hash parameters, compact metadata, and payload layout. At mount time, CoFS does not rebuild a tree or populate all dentries. A lookup calculates an index, reads the corresponding metadata record, and verifies the name when necessary. The authors report that most lookups require less than one storage I/O on average because adjacent metadata can arrive in the same read. Long names may require an extra access, which is why the claim is an average rather than a universal one-I/O guarantee.
MPHF construction is offline work. On randomly generated graphs, the average build computation rose from 0.016 seconds for 1,000 nodes to 34.042 seconds for one million nodes, with a 63.24-second maximum in the reported trials. A production image already takes minutes to assemble and compress at that scale, so the added indexing step is small in that workflow. It would be a poor fit for a namespace whose entries change after publication because updates would invalidate the compiled mapping.
A second index removes serial path depth
Direct lookup within one directory does not remove dependency between path components. The kernel normally resolves /a/b/c from the root downward and cannot request c until it knows b. Deep image paths therefore expose a serial chain even when each individual lookup is fast.
CoFS builds a second MPHF over absolute paths and uses it for parallel lookup. For paths deeper than three levels, an instrumented open path sends the absolute name to a kernel workqueue. That worker traverses layers from the leaf upward, hashes each absolute prefix, and constructs missing inodes. The ordinary kernel walk continues from the root at the same time. If the reverse worker encounters an inode already resident in memory, it can stop because top-down kernel lookup guarantees that the inode’s ancestors have already been instantiated.
This is not speculative data prefetch. It is parallel metadata materialization using a namespace that was fixed and indexed earlier. The optimization helps when the path is deep enough to amortize workqueue and hashing overhead. Elasticsearch showed a 28% reduction in average lookup time relative to CoFS with parallel lookup disabled. A shallow image or a warm dentry cache offers less headroom.
Sparse host files preserve the kernel data path
Lazy image systems must remember which byte ranges have arrived and fetch missing ranges from the repository. CoFS represents each image data object with a sparse file in the host filesystem. Downloaded extents fill that file at fine granularity. Once present, data is read through kernel filesystem and page-cache machinery rather than copied through a FUSE daemon.
The evaluation’s cached-file experiment used a 100GB random file inside an Ubuntu 22.04 image. After one complete read downloaded it, the researchers cleared the host page cache and ran fio inside the container. Traditional extracted storage, Nydus with EROFS and fscache, and CoFS produced almost identical results because all three reached downloaded bytes through kernel components. Nydus-FUSE and eStargz were slower because their cached-data paths still involved userspace.
This distinction matters operationally. Lazy pulling is not one property. Metadata resolution, miss handling, persistent extent caching, and warm-cache reads can cross different protection and scheduling boundaries. A design that optimizes the first miss but leaves every later read in a daemon may improve cold start while taxing steady-state service. CoFS tries to keep only repository misses on the exceptional path.
The comparison isolates a constrained repository
The prototype modified Linux 6.9.1 and stargz-snapshotter 0.15.1. Experiments ran on dual ten-core Xeon E5-2640 v4 processors, 128GB of memory, a 4TB HDD, and a dual-port 1GbE NIC. The image repository ran on another machine across the gigabit network. That setup intentionally represents a shared repository with limited download bandwidth, not a modern local NVMe cache or a high-bandwidth datacenter fabric.
Cold-start tests compared CoFS, gzip-compressed CoFS, traditional eager images, Nydus-FUSE, Nydus-EROFS, and eStargz. Each container was started ten times, clearing caches between trials, and readiness was measured at a service-specific output rather than process creation. Nydus and eStargz were also tested with background download enabled.
CoFS started every tested container faster than the evaluated alternatives. Background downloading generally hurt because the full image was much larger than the bytes needed before readiness; the transfer consumed the same constrained link and local I/O resources as foreground misses. This finding should not be generalized into a ban on prefetch. With a faster repository path, repeated later requests, or an accurate working-set predictor, background transfer can change the tradeoff.
SystemTap measurements placed the metadata result more precisely. Compared with a loopback FUSE filesystem, CoFS reduced average lookup time by 73% to 86%. The baseline is useful for isolating FUSE lookup overhead, but it is not an end-to-end claim that every production container will start 73% faster. Ready time also includes downloads, decompression, runtime initialization, application work, and cache state.
The format trades mutability for predictable work
CoFS gains direct addressing because no file is added, removed, or renamed after image construction. Containers that write use a separate writable layer; the read-only base remains compiled. Garbage collection, image signing, deduplication, and content-addressed distribution still need to treat the CoFS artifact and its hash metadata as one authenticated unit.
The kernel extension is another deployment boundary. Keeping warm reads in kernel space reduces context switches, but it expands code that must be maintained across kernel releases and reviewed for malformed images. A minimal perfect hash maps known keys without collision; it does not by itself authenticate metadata or reject an attacker-controlled unknown key. Integrity must come from the surrounding image-verification chain and from validating the record reached by the hash.
Sparse-file caching shifts capacity management to the host filesystem. Operators need visibility into logical image size, physically allocated extents, download misses, eviction, and cache sharing across containers. A large logical sparse file is not a large allocation, yet backup or copy tools that expand holes can turn it into one. Repository and node tooling must preserve sparseness.
Startup optimization needs four separate counters
A useful rollout should measure bytes requested before readiness, metadata lookups, repository-miss bytes, and warm cached-read cost independently. Those counters distinguish four failure modes: an image with a large true working set, a namespace with expensive traversal, an overloaded repository, and a userspace path that remains expensive after caching.
CoFS is strongest when images are large, startup touches a small and repeatable subset, paths are deep, and nodes retain cached extents. It is less compelling for tiny images, continuously changing trees, or environments where image transfer is already local and metadata time is negligible. The paper turns that placement decision into measurable conditions instead of treating all container cold starts alike.
The broader systems lesson is that on-demand loading needs a fast second access, not only a fast first launch. CoFS compiles immutable metadata, overlaps path work, and gives downloaded data back to the kernel. Its results show that the architecture of the cache hit can matter as much as the policy deciding which bytes to fetch.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the design, evaluation conditions, measurements, and limits in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX FAST 2026 presentation page. Copyright remains with the authors, 2026.