Container images are organized for distribution and storage, not for the first seconds of one service. A base image may contain package managers, compilers, libraries, and alternate entry points that a particular deployment never touches. Pulling every layer delays launch. Lazy loading removes that initial barrier, but a sequence of page faults can replace one large transfer with thousands of small file, chunk, or block requests.
The mismatch is structural. An application reads pages while conventional image services fetch storage objects at larger and differently aligned granularities. The measurements put worst-case I/O amplification at 3.1-fold and attribute as much as 90% of lazy-start overhead to the network path[1]. Random access also creates hundreds of thousands of packets, so available bandwidth is lost to request processing and latency.
FlacIO records the page working set for a named service and builds a contiguous runtime image. At launch, a host transfers that compact object and inserts its pages into a kernel-managed cache that OverlayFS can use directly. Missing pages still fall back to the underlying lazy loader. The design does not replace the container image ecosystem; it adds a service-specific acceleration layer whose unit is expected memory state.
A service-specific working set replaces a global layer view
Conventional images are storage-oriented because they reproduce a root filesystem and global because the same artifact supports many entry points. This property is useful for distribution and reuse, but it prevents the registry from knowing which bytes one service needs before it accepts traffic. Lazy systems discover the set online, paying one miss at a time.
FlacIO creates a runtime image by starting the service with probes around its readiness boundary. It traces root-filesystem page accesses, sends the trace to the registry, extracts the referenced data from the base image, removes duplicates, and lays pages out contiguously. File indexes and page tables map the compact data back into the container namespace. Generation is asynchronous and the original image remains authoritative.
The readiness probe is part of correctness. A web daemon can stop tracing when its port accepts requests, while a framework image may stop after importing PyTorch or TensorFlow. A probe that ends too early omits startup pages and increases fallback traffic. A probe that runs too long stores request-specific data and weakens sharing. Runtime images therefore belong to a service version and a defined readiness contract, not merely an image digest.
Flat transfer needs a kernel landing point
A compact object is insufficient if the host must unpack it through the same file and block stack that caused amplification. FlacIO adds a runtime page cache (RTPC) beneath OverlayFS and above the ordinary VFS page cache. New primitives copy the runtime image into kernel memory and associate its pages with files in the root namespace. A hit avoids the lazy filesystem’s request path; a miss redirects normally.
RTPC lets the same pages serve multiple containers without a second user-space cache. Existing lazy loaders often keep fetched data in an internal cache while VFS also caches file pages, creating double storage in memory. FlacIO loads startup pages directly into the cache where applications consume them. The Nydus combination used between 1.1% and 24% of comparison systems’ memory in the reported tests, although the exact ratio depends on each loader’s caching policy.
Service-specific images can overlap heavily when they share a base. FlacIO supports incremental injection and deduplicates pages so a second service adds only its missing working set. It also falls back when no runtime image exists or a page was not traced. This compatibility boundary matters because a trace cannot enumerate every branch, locale, plugin, or input-dependent file.
The evaluation separates startup from steady state
The test host had a 24-core 2.30 GHz x86 processor, 256 GiB DRAM, openEuler 22.03 with Linux 6.5, Containerd 1.7.1, and a 10 Gb/s link to the image registry. Comparisons included full Containerd pulls, CRFS and Nydus file-oriented lazy loading, DADI block loading, DADI with a collected trace, and FlacIO layered on CRFS or Nydus.
Cold startup was measured to service readiness, not process creation. Daemons used successful access to an HTTP port; PyTorch and TensorFlow used completion of core-library imports. Across six services, FlacIO reduced latency by up to 4.5 times against lazy systems and 23 times against full-image loading. For TensorFlow, the reported startup reductions are 3.7-fold against CRFS, 3.9-fold against Nydus, and 2.8-fold against DADI.
Warm startup was similar across lazy systems because pages were already local. FlacIO added only the mount and redirection path and did not materially increase the reported warm latency. This distinction prevents a cold-start optimization from being credited for cached cases. Its benefit appears when a host lacks the service working set, especially for images with many files and scattered startup reads.
Fewer packets matter as much as fewer bytes
Tracing alone improves accuracy but keeps remote I/O fragmented. In the factor analysis, probe-based selection reduced Postgres and PyTorch latency by more than 8.6% and 22.8%, while adding RTPC and the flat runtime object contributed reductions of 24.2% and 50.0%. The cache path accounted for an average 1.41% of total startup overhead.
For PyTorch, existing lazy loaders transferred 29 times less data and used 6.3 times fewer packets than a full pull, yet still sent at least 1.6 times more bytes and 4.4 times more packets than FlacIO. A DADI trace replay transferred 1.6 times more data than FlacIO for both Postgres and PyTorch because requests were not coalesced into one contiguous object. Accurate selection and collective transfer solve different parts of the problem.
Runtime images consumed 262.8 MiB for nine services, equal to 6.0% of compressed CRFS base images and 4.7% of compressed Nydus images. This is registry capacity exchanged for startup bandwidth and latency. The paper’s approximately 5% figure is favorable when the same service starts frequently; one-off or rapidly changing images may spend more build and storage work than they recover.
A trace is a prediction with an escape path
Service behavior changes with application versions, environment variables, plugins, CPU features, and input. A runtime image must be invalidated or regenerated when those determinants change. A miss remains correct because the original lazy loader supplies the page, but many misses erase the performance benefit and can recreate a burst of small network requests.
Security stays at the existing container boundary. RTPC uses kernel page-cache sharing, while namespaces and cgroups continue to isolate runtime behavior. The paper does not claim confidentiality for shared pages beyond current container semantics. Registry integrity, image signatures, and page-to-file mapping validation must cover the derived runtime object just as they cover base layers.
Operational counters should include runtime-image hit ratio before readiness, fallback requests, bytes and packets per cold start, trace age, incremental-page reuse, registry storage, and memory retained after launch. A platform can then retire stale runtime images and identify services whose behavior is too variable for precomputation.
The denominator is ready service per transferred request
The strongest use case is repeated cold placement of a stable service on nodes without its cache. Autoscaling, disaster recovery, and batch workers can reuse the same runtime image many times. FlacIO reports up to 55% faster cluster scaling and application improvements up to 2.25 times for object storage and 1.7 times for machine-learning training, but those end-to-end results include each workload’s startup frequency.
The method is less compelling for long-lived containers, warm pools, or images whose startup path depends heavily on tenant data. Network speed also changes the balance. A faster registry link lowers transfer time but may leave per-request latency and CPU overhead; a slower or distant registry increases the value of aggregation. Results from one 10 Gb/s host-to-registry setup should not be treated as a universal ratio.
Procurement should compare completed ready instances per registry byte, packet, host-memory byte, and stored runtime-image byte. Full image pulls optimize compatibility, lazy loading optimizes bytes, and FlacIO optimizes the known service working set plus request granularity. The design is valuable when the working set is predictable and repeated. Its fallback makes prediction errors correct, while observability determines whether they remain economical.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the mechanism, 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 2025 presentation page. Copyright remains with the authors, 2025.