When engineers specify storage for roadside traffic cabinets, most of the attention goes to the hardware: flash versus spinning disk, write-endurance ratings, form factor, vibration tolerance. The filesystem layer gets far less scrutiny. That's a mistake. The filesystem sitting between your storage hardware and your traffic control software determines whether operational data survives an unplanned power loss, how quickly a controller unit mounts its volumes after a restart, and how aggressively write cycles are distributed across the media. Getting this wrong doesn't just risk data corruption. It can shorten the service life of expensive industrial-grade drives and complicate regulatory compliance.
Why filesystem choice matters more in roadside cabinets
A server room has stable power, climate control, and a UPS sized to carry the load through any realistic outage. A roadside traffic cabinet has none of those guarantees. Power interruptions caused by vehicle strikes, mains faults, or maintenance switching can cut supply in milliseconds. If a write operation is mid-flight when power drops, the resulting partial write can corrupt not just one file but the entire directory structure, depending on how the filesystem handles journalling.
Journalling filesystems record pending writes to a separate log before committing them to the main data area. If power drops, the journal lets the system replay or discard incomplete transactions on the next boot. Without journalling, the controller unit must run a full consistency check on startup, which on a busy volume can take minutes. That's minutes during which the intersection reverts to a default or flashing mode. As covered in the discussion of backup power and data integrity in traffic cabinet storage, even short recovery windows carry real operational risk.
Cabinet storage also differs from enterprise storage in how writes arrive. Traffic controllers generate continuous, small, high-frequency writes: detector loop events, phase change timestamps, fault codes, and comms logs. This write pattern is punishing for filesystems that weren't designed for it, and it interacts badly with certain allocation strategies that fragment data rapidly under sustained small-write loads.
The main filesystem options in industrial deployments
Four filesystems appear most often in Australian traffic and ITS cabinet deployments. Each has a different profile for journalling behaviour, write amplification, and resilience to abrupt power loss.
ext4 is the default on most Linux-based controllers. It journals metadata by default and can be configured to journal data as well, at a write-performance cost. Ext4 handles the small-write patterns of traffic logging well, and its fsck tool is fast enough on typical cabinet volumes (16 GB to 128 GB) that recovery after a dirty shutdown completes in under 30 seconds. It's a practical choice when the controller runs a mainstream Linux distribution and when the integrator wants a predictable, well-documented behaviour baseline.
F2FS (Flash-Friendly File System) was designed specifically for NAND flash storage. It reduces write amplification by aligning its internal data structures to the erase-block boundaries of flash media, which means fewer unnecessary erase cycles per logical write. On systems where the storage is a fixed flash module with a finite write-endurance budget, F2FS can meaningfully extend the usable service life. The tradeoff is that F2FS has less mature tooling than ext4, and recovery from severe corruption requires more specialist knowledge.
SquashFS with an overlay is used in some hardened deployments where the base operating system and configuration are stored read-only, and only a small overlay volume handles runtime writes. This approach almost eliminates corruption risk for the OS layer because a read-only filesystem can't be corrupted by a write interruption. The overlay volume still needs its own journalling strategy, and this architecture adds complexity to software update procedures.
JFFS2 and UBIFS appear on older embedded controllers using raw NAND flash (without a flash translation layer). Both were designed for this environment and handle wear levelling and bad block management at the filesystem level rather than relying on the storage device. In newer deployments these have largely been replaced by eMMC or industrial SSD modules with their own translation layers, making ext4 or F2FS more appropriate.
Journalling modes: the detail that matters most
Filesystem journalling isn't binary. Ext4, for example, offers three modes.
Writeback mode journals only metadata. Data blocks are written directly without journalling. This is the fastest mode but leaves a window where metadata and data can be inconsistent after a crash. A file might appear in the directory but contain garbage. For traffic logging, this is generally too risky.
Ordered mode (ext4's default) also journals only metadata, but enforces that data blocks are written to disk before the metadata journal entry is committed. This closes the worst corruption window without the full overhead of data journalling. Most traffic controller deployments that use ext4 stay in ordered mode.
Journal mode journals both metadata and data, giving the strongest consistency guarantee at the cost of roughly double the write I/O. On a system generating thousands of small writes per hour from detector and phase logging, this amplification matters for media longevity. It's worth considering for safety-critical log archives that must survive any power scenario, but for general operational data ordered mode is the more practical balance.
The journalling mode selection interacts directly with write-endurance budgets. An article covering write-endurance limits in industrial storage sets out how to calculate available write cycles against a deployment's expected log volume, which is the right starting point before deciding how aggressive to be with journalling.
Mount options that change real-world behaviour
Beyond the filesystem type and journalling mode, mount options have a measurable effect on data integrity and media wear.
The noatime option disables access-time updates on file reads. By default, every file read triggers a metadata write to record when the file was last accessed. In a cabinet that reads configuration files and log archives thousands of times a day, this generates write traffic with no operational value. Disabling it with noatime or relatime reduces write amplification without any impact on traffic control function.
The errors=remount-ro option instructs the kernel to remount the volume read-only if it detects a filesystem error, rather than continuing to write to a potentially corrupted structure. This is the correct failure mode for a traffic cabinet: it stops further damage and generates a fault event that the controller can log and escalate, without silently writing over corrupted data.
The barrier=1 option (default in ext4) ensures that journal commits are flushed to stable storage before any subsequent writes proceed. On storage devices that have a write cache, disabling barriers can silently reorder writes in a way that defeats journalling. Industrial storage modules with capacitor-backed write caches can safely disable barriers, which improves throughput. Modules without this protection must not.
Partition layout and its effect on recovery time
How the storage volume is partitioned affects both recovery speed and the blast radius of a corruption event. Putting the operating system, configuration data, and operational logs on a single partition means any corruption event potentially affects all three. A controller that can't mount its config partition can't run a valid signal plan; a controller that can't mount its log partition still runs, but loses audit data.
A practical layout for traffic cabinet storage separates at minimum the read-only OS root, the read-write configuration store, and the operational log volume. Each partition can be sized to its expected write load, journalled at the appropriate mode, and recovered independently. If the log volume fills or corrupts, the controller keeps running on valid configuration. This is the same principle that underlies RAID separation strategies: isolating failure domains so that one failure doesn't cascade.
Filesystem selection as part of a wider storage specification
Filesystem decisions don't sit in isolation. They interact with the storage hardware type, the controller's Linux kernel version, the power backup architecture, and the data retention obligations the system must satisfy. A deployment using F2FS on industrial eMMC with a capacitor-backed write cache and ordered journalling represents a coherent, well-matched stack. A deployment using ext4 in writeback mode on a consumer-grade SSD without power-loss protection represents a stack where the components are working against each other.
Bob Panich Traffic Signals specifies storage stacks for ITS and traffic signal infrastructure with attention to how each layer interacts: filesystem, media, power architecture, and the write patterns generated by the specific controller platform. Filesystem selection is part of that specification process, not an afterthought left to default settings.