Modern roadside traffic cabinets increasingly host more than one operational system on a shared storage device. A signal controller, a local SCATS or STREAMS node, an incident detection module, and a connected vehicle data receiver can all compete for read and write access on the same flash medium. Without deliberate storage partitioning, these co-resident systems interfere with each other in ways that are difficult to diagnose and can compromise intersection safety. This article explains the partitioning approaches used in multi-tenant traffic cabinet deployments, where each fails, and what specifiers should require.
Why multi-tenancy in traffic cabinets is growing
A decade ago, most roadside cabinets ran one controller with a narrow software stack. Today, adaptive signal control platforms, edge analytics modules, V2X communication stacks, and data logging agents routinely share the same physical enclosure. Cabinet size and power budget constrain how much hardware can be added, so consolidation onto shared storage is a practical reality rather than an engineering preference.
The problem is that each tenant has a different write profile. A signal controller writes small, frequent status records. A video analytics module flushes large buffers in bursts. A data logger runs near-continuous sequential writes. On an unpartitioned volume, these profiles combine into an unpredictable I/O pattern that accelerates wear and introduces latency spikes at the worst possible moments.
Partition schemes and what they actually protect
Three partitioning approaches appear in practice, and they don't protect against the same failure modes.
Fixed-size primary partitions are the simplest arrangement. Each tenant gets a dedicated volume carved from the raw device at provisioning time. Capacity isolation is guaranteed: one tenant can't consume another's space. What fixed partitions don't prevent is I/O queue contention at the controller level, because the storage device still serialises all writes regardless of which partition they target. On a single NAND die, two tenants writing simultaneously still compete for the same program-erase cycles.
Logical volume management (LVM) with I/O cgroups adds a second protection layer by attaching bandwidth limits and queue-depth caps to each logical volume at the operating system level. A data logging agent bursting at 40 MB/s can be capped at 10 MB/s, reserving the remaining throughput for the controller's latency-sensitive writes. This is the architecture Bob Panich Traffic Signals recommends for cabinets running three or more co-resident software tenants on a single storage medium.
Separate physical devices per tenant is the only approach that eliminates all storage-level interference, because each tenant's writes go to distinct NAND or independent flash packages. It carries a cost in cabinet space, power draw, and provisioning complexity. For safety-critical tenants, separate physical storage is worth specifying. The signal controller and its conflict monitoring logs should not share a device with a higher-frequency, less critical analytics workload.
Protecting real-time writes from background processes
The most common failure mode in multi-tenant storage is background garbage collection blocking a real-time write. Flash storage devices consolidate valid data and erase stale blocks in background garbage collection cycles. If a burst write from an analytics tenant triggers a large garbage collection pass at the same moment the signal controller needs to commit a timing-plan change, the controller write queues behind the erase operation. Latency spikes of 50–200 milliseconds are documented in production deployments.
Two mitigations address this directly. First, over-provisioning the device by at least 20 percent gives the flash translation layer headroom to run garbage collection asynchronously rather than synchronously on write paths. Second, scheduling high-volume tenant writes to off-peak windows (typically midnight to 05:00) keeps garbage collection pressure low during peak signal operation hours. This dovetails with log rotation policies, which should be timed to the same off-peak window to avoid compounding the write load.
Filesystem choices within each partition
Partition boundaries define the capacity envelope. The filesystem choice within each partition determines how writes behave under power interruption, which is the dominant failure scenario in roadside cabinets. Each tenant's partition should carry a filesystem matched to its write profile, not a single filesystem applied uniformly across the device.
A signal controller partition benefits from a journalling filesystem (ext4 with journal_async_commit, or F2FS in its integrity mode) where the cost of a journal write is acceptable given low write frequency. An analytics buffer partition can tolerate F2FS in performance mode, accepting a slightly higher corruption risk on sudden power loss in exchange for lower write amplification. A read-mostly configuration partition can run on a read-only squashfs mount, eliminating wear on that area entirely. The point is that filesystem selection is a per-tenant decision, not a per-device one.
Access control and tenant isolation at the OS layer
Storage partitioning is a physical and logical boundary. It isn't, on its own, an access control boundary. A software process with sufficient privilege can read from or write to any mounted volume. In multi-tenant cabinet systems, each tenant's storage mount should be accessible only to that tenant's process user, enforced through Unix permissions and mount namespace isolation where the cabinet OS supports it.
This matters because traffic cabinet systems increasingly run software from different vendors on the same hardware. A third-party analytics module that can write to the signal controller's partition represents a data integrity risk and, depending on the data held, a cybersecurity exposure. Namespace isolation is a straightforward control that cabinets provisioned with container-aware Linux distributions can implement without additional hardware.
Testing and commissioning multi-tenant storage configurations
A partitioned storage configuration that passes bench tests can still fail in the field if commissioning doesn't replicate the actual concurrent write load. Testing each tenant in isolation validates only single-tenant behaviour. Acceptance testing should run all tenants simultaneously at their expected peak write rates, sustained for at least four hours, while monitoring write latency on the signal controller partition specifically.
Bob Panich Traffic Signals includes concurrent I/O load tests in commissioning checklists for all multi-tenant cabinet deployments. Latency on safety-critical partitions must not exceed 5 milliseconds at the 99th percentile during combined load. Any spike above that threshold warrants investigation of the partition layout and over-provisioning ratio before sign-off.
For projects where the storage architecture feeds into a broader digital twin or city data platform, the partition scheme also shapes what data can be reliably ingested upstream. A storage configuration that drops records under load undermines the accuracy of any digital twin data pipeline that depends on continuous, complete cabinet logs.
What to specify when procuring shared-storage cabinets
Procurement documents for traffic cabinets with shared storage should require the supplier to state: the number of logical partitions provisioned, the I/O bandwidth limits applied to each partition, the over-provisioning ratio of the storage device, and the filesystem type on each partition. Without these specifics, a compliant-sounding response can conceal an unpartitioned or under-provisioned deployment.
Bob Panich Traffic Signals designs and supplies traffic signal infrastructure across Australia, including storage architecture for multi-tenant cabinet systems built to the operational demands of state and local transport authorities. Specifiers requiring detailed storage configuration documentation for procurement packages can contact Bob Panich Traffic Signals directly for technical input at the design stage.