akougkas.io

One destination, N tiers

Every tier supplies the application at once, and the application sees one destination. The thesis from a November 2026 talk to my group at the Gnosis Research Center, the six lines of I/O work behind it since 2016, and my bet that they are the foundation agents need for context.

Published
Reading
9 min read
Topics
systems, data, agents, scientific computing

The argument

  1. Every tier supplies the application at once, and the application sees one destination.
  2. Placement, intent, task, order, runtime, and measurement are six lines of one program, and each converges on context.
  3. Agents are a new client for the same hierarchy, so the I/O line built since 2016 is the right foundation for assembling their context.

On Wednesday, November 11, I gave a talk to my group at the Gnosis Research Center about what happens after the data leaves memory. Most of the room builds I/O systems, and many of them are building the newest pieces of the line I describe here. The talk had one thesis, and I put it on a slide by itself: every tier supplies the application at once. The application sees one destination.

Download the slides (PDF)

The hierarchy nobody chooses

None of us has ever chosen which cache level a variable lives in. That invisibility is forty years of architecture work, some of it done in our own lab, and it holds because one architect designs every level of one machine.

Below DRAM there is no such invisibility. From IBM’s first disk drive in 1956 until flash reached the data center, there was disk and then tape. Then four families of hardware arrived: flash, NVMe, and burst buffers; byte-addressable persistent memory such as Optane; disaggregated memory and storage over CXL, RDMA, and NVMe over Fabrics; and storage attached directly to accelerators through HBM and GPUDirect Storage. Software support arrived one device at a time. Intel wound Optane down in 2022, and software written against Optane went with it. Software written against the hierarchy kept running.

An I/O tier is not another cache level. It is shared by many jobs and many owners, it fails on its own, it is persistent and carries durability semantics, and it answers in microseconds to seconds instead of nanoseconds. The principle is the one the lab’s memory-systems work states for the inside of the machine: match the rate of requests to the rate of supply at every layer. Same principle, different problem, different machinery.

Where the line started

In 2015 and 2016, Cray’s DataWarp burst buffers arrived on Cori and Trinity. A new tier showed up on leadership machines and the first question was who manages it. Jobs interfered with each other on the shared tier, and BBIO, my eScience 2016 paper with Matthieu Dorier, Rob Latham, and Rob Ross at Argonne, coordinated burst buffers to prevent that interference and improved performance by up to 2x. Harmonia followed as an interference-aware scheduler for shared burst buffers, and IRIS put files and objects behind one interface, which Kun Feng carried into NIOBE.

Single tiers had managers: DataWarp for the burst buffer, Data Elevator between burst buffer and file system, hierarchical storage management for tape. Each of our early papers also tamed one tier or one interface. The machines already had five tiers, and nothing managed the hierarchy as one.

Six lines

The thesis rests on six ideas. Each one has a name, a system, and people who built it.

Line The question Systems Built by
Placement Which tier holds the data now? Hermes, then the CLIO Context Transfer Engine Hari Devarajan and I; runtime by Luke Logan
Intent What does the application want? LABIOS Hari and I, with Jay Lofstead and Kathryn Mohror
Task What work travels with the data? DTIO, now in CLIO Core Keith Bateman, with Bogdan Nicolae and Franck Cappello
Order What happened first? ChronoLog Hari and I first; Kun Feng and Eneko Gonzalez wrote most of today’s code
Runtime What executes the decision? The Hermes runtime, LabStor, Chimaera, the CLIO Runtime Luke Logan
Measurement What is actually happening? DLIO, DFTracer, WisIO Hari, with Argonne and Livermore; Izzet Yildirim

Placement. Hermes, the multi-tier I/O buffering system in our HPDC 2018 paper, treats RAM, NVMe, burst buffers, and the parallel file system as one buffer. Placement is solved per request, not fixed per device: if a request fits in a layer, place it; otherwise skip to the next layer, split it, or flush and recurse on what remains. Hermes was 8x faster than no buffering and more than 2x faster than Data Elevator and DataWarp, and it needed no application changes. Once tiers exist, every classic optimization gains a new variable, which tier, and Hariharan Devarajan’s HFetch, HCompress, and HReplica answered it for prefetching, compression, and replication.

Intent. Every one of those algorithms inferred what the application wanted from its I/O calls. POSIX throws that away. LABIOS, our label-based I/O system (HPDC 2019, with Jay Lofstead and Kathryn Mohror), puts it back. A label is an operation, a data pointer, and flags, and once I/O is labels, storage becomes a scheduling problem. I used to call labels an optimization. I now see them as intent preserved across a system boundary.

Task. DTIO, Keith Bateman’s task-based I/O system with Bogdan Nicolae and Franck Cappello at Argonne, turns the label into a DataTask that carries formats, ordering, and dependencies, so translation runs online and producer and consumer overlap. On PtychoNN it cut time by 49.6 percent against offline translation (SSDBM 2025). Its mechanisms now live in CLIO Core.

Order. ChronoLog, a distributed shared log ordered by physical time (MSST 2020), asks what happens if the data carries its own placement key. Physical time is the log sequence number, so a writer knows where its entry goes without asking a sequencer. The prototype sustained over a million tail operations per second. The log’s age order matches the hierarchy’s speed order, newest in RAM and oldest in the archive, and version 3.0 added SQL, publish and subscribe, and an MCP server in May 2026.

Runtime. Every system kept rebuilding the same runtime. Luke Logan built it once and kept rebuilding it better: the Hermes runtime, then LabStor, modular I/O stacks in user space, then Chimaera, where every module is a pool of tasks on shared-memory queues, and now the CLIO Runtime. His MegaMmap put the same tiers behind a memory interface. Build the runtime once, and every system after it is a module.

Measurement. You cannot place what you cannot see. DLIO is Hari’s benchmark of how scientific deep learning does I/O, built with Huihuo Zheng and Venkat Vishwanath at Argonne. Its later development and its place as the workload engine of MLPerf Storage are Argonne’s work, mostly Hari’s, and I was part of the Illinois Tech team that co-advised him. At Livermore, Hari built DFTracer, and Izzet Yildirim’s WisIO reads one trace from many views to classify bottlenecks from metrics rather than fixed rules.

None of this was one person’s work, and the line passes through five dissertations. Mine, on data labels, gave Harmonia, Hermes, and LABIOS. Kun’s integrated files and objects. Hari’s made storage tier-aware and measurable. Luke’s built the runtime. Jaime Cernuda’s built the data flows and pipelines that now carry CLIO Agent and Relay. Each handed its ideas to the next, and all five continue in IOWarp.

The same pyramid, different hot data

In 2018 the hot data in our pyramid was a checkpoint: RAM, NVMe, burst buffer, parallel file system. In 2025 the hot data is a KV-cache, the attention state a language model keeps per token, and the pyramid is GPU HBM, host DRAM, local SSD, and networked object storage. NVIDIA Dynamo, LMCache, and Mooncake all tier KV-cache blocks down that hierarchy. Industry arrived at the same pyramid independently, and that is the best evidence I know that the problem is real. Jie Ye’s measurements of KV-cache I/O under concurrency are part of how our group came to see it.

The next hot data is the context an agent needs for one decision. I made the argument that the client changed at an Argonne seminar last year: a program’s unit of work is the byte and its access is periodic and knowable, while an agent’s unit of work is the decision and its requests are semantic and produced by reasoning. Context is the slice of data, metadata, provenance, system state, tool capability, and history that one decision needs. Assembling that slice on time, from every tier, is an I/O problem.

The bet

My bet is that the line we have built since 2016 is the right foundation for agent context. Not because the systems were designed for agents, since none of them was, but because context is assembled from every tier at once and handed to a client that should see one destination. That is the thesis, with a new client.

Each line already has a home in the CLIO stack, the context layer for scientific AI agents that I created for IOWarp. Placement lives in CLIO Core’s Context Transfer Engine, which is Hermes grown up: its policies became a chain of interposers on one task interface, cache, then compressor, then replication, then core. Intent and task live in CLIO Core. Order is ChronoLog as an agent’s history. Runtime is the CLIO Runtime. Luke leads Core engineering, and the 2.3 and 2.4 releases taught it to evict from a full tier, lose no data when a tier goes offline, and run on Aurora’s Intel GPUs. Jaime leads CLIO Agent and Relay. Isa Muradli, Shazzadul Islam, Soham Sonar, and Aum Sathwara build CLIO Kit, the MCP servers for scientific formats and tools. I build CLIO Coder. Two DOE Genesis Mission projects, SPOTTER-AI led by Argonne and PORTUS led by PNNL, build on CLIO, and the full stack launches at SC26 in Chicago, November 15 to 20.

The measurement line is the youngest. For agents it means characterizing agents as an I/O workload, and several students in the group are now doing exactly that. Agents read, write, and revisit context in patterns that our storage stacks were never tuned for, and nobody has measured them carefully yet. If agent context turns out to be a first-class I/O workload, every tier in the hierarchy has a new tenant to serve. The other five lines tell us where context should live and how it should move. Measurement is how we will learn whether agents need it the way I think they do.

What the line taught me

None of these lessons is about I/O. The system existed before the project did: Hermes was a paper and a prototype before it was funded. One line of work compounds: one runtime, from Hermes to LabStor to Chimaera, now sits under everything we ship. Software makes an idea negotiate, with compilers, failures, other people’s workloads, and the cost of being understood. And the abstraction outlives the code. Hermes’s final release was in 2024, and its placement model runs inside CLIO today.

None of these systems started because someone asked for them. Each started because someone in the lab saw a thing that should exist and began building it well. Pursuing excellence does not need justification.

Sources, code, and records

  1. source

    Talk slides (PDF)

    The 28-page deck from November 11, 2026, including an appendix with one slide each for Hermes, ChronoLog, and IOWarp and CLIO.

  2. source

    Hermes paper

    The HPDC 2018 design for placement across a deep memory and storage hierarchy.

  3. source

    LABIOS paper

    The HPDC 2019 paper on label-based I/O, Karsten Schwan Best Paper.

  4. source

    ChronoLog paper

    The MSST 2020 design for a log ordered by physical time.

  5. source

    DTIO paper

    Keith Bateman's SSDBM 2025 paper on data tasks with online transformation.

  • 2018–2024
    complete

    Hermes

    Multi-tier I/O buffering for HPC storage hierarchies

  • 2017–present
    evolving

    LABIOS

    Label-based I/O for HPC and Big Data storage systems

  • 2020–present
    active

    ChronoLog

    A distributed shared log ordered by physical time

  • 2023–2026
    complete

    DTIO

    Task-based I/O with online data transformation and provenance

  • 2024–present
    active

    IOWarp

    Context management infrastructure for scientific AI

  • 2025–present
    active

    CLIO

    A context layer for scientific AI agents and workflows

More on Hermes

  1. essay

    When is research software shipped?

    A working definition of "shipped" for research software, built around a named state someone else can run, evidence tied to that state, explicit limits, and a continuity signal, with Hermes and DLIO as the worked examples.

    7 min
  2. essay

    From storage optimization to context orchestration

    Twenty years of I/O research optimized bytes per second for programs. Agents are a different client, and each system in our lineage contributes one primitive to serving them, as argued in a seminar at Argonne.

    8 min
  3. update

    CLIO Core 2.3 and 2.4: when a tier fills or a node dies

    Four CLIO Core releases between October 9 and November 2, 2026 added a device-paged GPU vector and Intel GPU support, then taught the context store to recover a full tier and keep data and directories readable when a node goes down.

    3 min