CppCon 2026

Embedded systems have to operate within real limits. We care about timing, memory usage, reliability, and what happens when something fails. But storage is often treated differently. We write a file, call an API, and assume the operation will finish when it finishes. That works for a lot of systems, but it becomes harder to accept when storage is part of a real-time workload.

That led me to a fairly simple question: what would change if storage had to be predictable too?

In this talk, I'll use an embedded filesystem I built in C++20 to explore that question. We'll start with the system requirements and work our way down into the filesystem, looking at where unpredictable work can come from and what design choices can make that work easier to understand and bound.

Instead of focusing only on average execution time, we'll look at what an operation actually has to do: searching for space, accessing metadata, reading and writing blocks, handling failures, and recovering from interrupted operations. We'll also look at how those costs change as the filesystem fills up or becomes fragmented. This kind of reasoning is familiar in real-time systems—we routinely think about bounded work in schedulers, queues, synchronization, and memory management. Storage deserves the same scrutiny.

The filesystem is intentionally constrained. It uses fixed resources and bounded searches where practical, explicit ownership, and a block-device interface that keeps the filesystem separate from the underlying storage hardware. I'll also show how fault injection and instrumentation can be used to exercise failure paths and measure the work being performed instead of relying only on timing measurements.

Modern C++ is useful here, but not because using C++ automatically makes a system deterministic. It gives us tools for making some of these design decisions explicit. We'll look at std::span, std::string_view, fixed-size containers, RAII, compile-time configuration, and small abstractions that can still make sense on a resource-constrained microcontroller.

There are tradeoffs. Fixed limits give up some flexibility. Simpler allocation strategies may use storage less efficiently. Recovery requires additional work and writes. In some systems those costs are worth paying for behavior that is easier to reason about. In others, a general-purpose filesystem is the better choice. We'll look at both sides.

We'll also separate the work performed by the filesystem from the timing behavior of the storage device itself. That gives us a way to take the same filesystem design and evaluate it across different storage backends and embedded targets. Rather than asking only, “How fast did this run?”, we can start asking, “How much work did the software perform, what did the hardware contribute, and did the system behave the way we expected?”

By the end of the talk, attendees should have a practical way to think about predictable storage in embedded C++ systems and, more broadly, how to reason about resource limits, failure handling, ownership, hardware interfaces, and timing when predictability matters more than peak performance.