When a roadside traffic cabinet loses power mid-write, the storage device doesn't always know which data made it to disk. The result can range from a mildly inconsistent log file to a completely unmountable filesystem. Journaling filesystems were designed to solve exactly this problem, and for industrial traffic storage they're not optional. Understanding how journaling works, and which modes actually protect against power-loss corruption, is a specification decision that belongs at the design stage, not after the first field failure.
What a journal does
A journal is a dedicated region of the filesystem that records intended write operations before they're committed to the main storage area. Think of it as a transaction log. When the system writes data, it first records the intended changes in the journal. Only once that record is confirmed does the filesystem apply them to the primary data structures. If power cuts out at any point, the next mount reads the journal, determines what was in flight, and either completes or discards those pending operations. The filesystem comes back consistent, even if some data from the interrupted write is lost.
Without a journal, an abrupt power loss can leave directory entries pointing to data that was never written, or partially overwrite allocation tables. A fsck scan at next boot can repair some of that, but fsck is slow and imperfect. On a traffic cabinet that's expected to restart quickly after a supply interruption, a five-minute forced filesystem check is not acceptable.
Journaling modes and what they protect
Most Linux-based traffic controllers use ext4, and ext4 exposes three distinct journaling modes with meaningfully different protection levels.
- Writeback mode journals metadata only, and makes no ordering guarantee between metadata and data writes. The filesystem structure stays consistent, but file contents can be corrupted or contain old data after a crash.
- Ordered mode (ext4's default) journals metadata only, but flushes data to disk before the associated metadata is committed. File contents are safe; only writes that were genuinely in-flight at the moment of loss are discarded.
- Journal mode journals both metadata and file data. It provides the strongest protection, but roughly doubles write I/O to the journal region, which adds wear on flash storage.
For traffic cabinet deployments, ordered mode is the practical default. It protects data integrity without the write amplification that full journal mode imposes on industrial flash. Writeback mode should not be used in any application where log files or configuration data must survive unclean shutdowns. That rules it out for nearly every traffic signal application.
F2FS and JFFS2: alternatives worth knowing
Not every traffic controller runs ext4. Flash-native filesystems like F2FS (Flash-Friendly File System) include their own journaling and checkpoint mechanisms designed specifically to reduce write amplification on NAND flash. F2FS uses a roll-forward recovery model: on mount after an unclean shutdown, it replays a compact node journal to reconstruct the filesystem state. Recovery is typically faster than ext4's journal replay on the same hardware.
JFFS2 (Journalling Flash File System 2) is older and suited to raw flash partitions without a flash translation layer. It's still seen in embedded ITS controllers based on NOR or NAND flash without an FTL. JFFS2 provides full data journaling by design, and its mount-time scan does full garbage collection, which makes initial boot time proportional to the volume of stored data. On cabinets with large log files, that matters.
The filesystem selection guide for industrial traffic storage covers the broader comparison between ext4, F2FS, and JFFS2 in detail, including the tradeoffs relevant to specific controller hardware.
Barrier writes and why they matter
A journaling filesystem's power-loss protection depends on the write barrier mechanism working correctly. A write barrier is an instruction to the storage device to flush its internal write cache and confirm all previous writes are on persistent media before proceeding. Without barriers, the filesystem may believe metadata is safely on disk when it's still sitting in a volatile drive buffer.
Some industrial flash devices advertise power-loss protection (PLP) using capacitors to drain the write cache on power failure. If the device has genuine PLP and the firmware signals this correctly, barriers are honoured in hardware. If the device doesn't, the filesystem can't rely on write ordering guarantees, and the journal protection largely unravels. Specify storage with confirmed PLP and verify that the device correctly reports barrier support via the kernel's block layer. Don't assume it.
This is particularly relevant in the context of backup power and data integrity in traffic cabinet storage: even with a UPS or supercapacitor in the cabinet, a storage device without hardware PLP can still corrupt data if the cabinet power fails faster than the backup supply engages.
Checkpoint intervals and tuning
Ext4's journal commits outstanding transactions on a timer (default: 5 seconds) and on explicit sync calls. This commit interval is tunable via the commit= mount option. Reducing it to 1 or 2 seconds tightens the window of data that can be lost after a crash, at the cost of more frequent journal writes. Increasing it above 5 seconds reduces write I/O but expands the exposure window.
Traffic signal controllers write small, frequent log entries throughout their operational cycle. A 5-second commit window means up to 5 seconds of event log data is recoverable only from the journal, not from the primary data area, after a power event. For fault logs used in post-incident compliance review, that matters. Tune commit intervals based on the write rate and the operational consequence of losing that window of data. There's no universal right answer.
Testing recovery before deployment
Journal configuration is easy to verify incorrectly because a filesystem that's misconfigured still mounts cleanly under normal conditions. The failure mode only shows under power interruption. Before deploying storage in a cabinet, run deliberate unclean shutdown tests: write a known dataset, cut power mid-write, remount, and verify filesystem consistency and data state. Do this across the temperature range the cabinet will experience, because flash write performance changes with temperature and so does the timing of interrupted writes.
Document the test results. Transport authorities and local councils increasingly require evidence of storage resilience testing as part of commissioning submissions, and having a test record for the specific hardware-filesystem-mount-option combination in your cabinet is more useful than a datasheet claim.
For reference, the approach to data integrity verification in industrial traffic storage covers checksum and scrubbing strategies that complement journaling, catching silent corruption that journal replay alone won't detect.
Practical specification checklist
When specifying journaling configuration for a traffic cabinet storage system, confirm these four things before sign-off.
- Journaling mode is set to ordered or full journal, not writeback.
- The storage device reports barrier support and has confirmed hardware power-loss protection.
- The commit interval is appropriate for the log write rate and the compliance window for that system.
- Unclean shutdown recovery has been tested on the target hardware, not just on a reference platform.
A filesystem that journals correctly doesn't make storage failures impossible. It does make them recoverable, which is a different and more useful property for infrastructure that operates unattended on the roadside.