|
Automotive infotainment and telematics electronics can write and read massive amounts of data from flash memory devices, and those devices must remain reliable and error-free for extended periods of time. The flash chip embedded in a vehicle navigation system, for instance, must survive many years of constant use. Users never expect to lose data, experience long boot times, or endure long data-recovery times. All this puts considerable demands on the file system technology that controls the data on flash chips.
To complicate matters, automotive embedded designs must keep costs to an absolute minimum. The bill of materials typically has no room for hardware that can manage power fluctuations or uncontrolled shutdowns, either of which can result in flash memory corruption and subsequent loss of service. Consequently, flash file system technology cannot simply provide high read/write throughput; it must also be self-healing and fully accessible within milliseconds after boot. (See a related article, "Fast booting techniques meet automotive infotainment/telematics activation needs".)
Figure 1: This in-car navigation system is an example of a device that requires a large, reliable flash file system (for 3D mapping, dynamic routing, etc.). Photo: SsangYong Motor Company
Transaction-based file systems
One technique for addressing these requirements is to employ a pure transaction-based model. The QNX embedded transaction file system (ETFS), for instance, follows this model and consists entirely of transactions. Every write operation, whether of user data or of file system metadata, consists of an "atomic" transaction. A transaction either succeeds or is treated as if it never occurred.
With this approach, the file system can survive across a power failure, even during an active flash write or block erase. To eliminate file corruption, transactions never overwrite existing "live" data. A write in the middle of a file update always writes to a new unused area. Consequently, if the operation can't complete due to a crash or power failure, the existing data remains intact.
Upon restart, the file system can roll back the write operation and complete it correctly, thus healing itself of a condition that would corrupt a conventional file system.
A transaction file system can build the file system hierarchy on the fly by processing the log of transactions in the device. This operation occurs at system boot, and should be designed so that only a small subset of the data needs to be read and CRC-checked. That way, the file system can achieve both high data integrity and fast restart times. QNX ETFS, for instance, can recover in tens of milliseconds, compared to the hundreds of milliseconds required by traditional file systems.
Figure 2: This device map illustrates independence from physical media in a pure transaction file system.
View a full-size image
As Figure 2 shows, each transaction in a pure transaction-based file system consists of a header and user data. The transaction header is placed into the spare bytes of the flash array. For example, a NAND device with a 2,112-byte page could comprise a 64-byte header and 2,048 bytes of user data. The transaction header identifies the file that the data belongs in and its logical offset, and contains a sequence number to order the transactions. The header also includes CRC and ECC fields for bit-error detection and correction.
At system startup, the file system scans these transaction headers to quickly reconstitute the file system structure in memory.
|
