File Systems in Real-Time Embedded Applications March 6th Eric Julien Balancing Performance, Safety and Resource Usage in an Embedded File System 1

Context This analysis is done using FAT. Its simplicity and lightweight implementations are a good choice for embedded systems with limited resources. Its compatibility with almost every OS makes it the default choice for removable devices. 2

Intro to performance File systems have multiple performance metrics RAM and ROM usage CPU usage Throughput Latency 3 The exact definition and measurement of performance is often application specific

The performance challenge There are a few “embedded considerations” that a file system suite often applies The overhead of copying data is major -> zero-copy stacks are often used (the stack uses application buffers as much as possible) RAM is limited -> Caching and buffering needs significant resources to be beneficial. Compromise between performance and reliability 4

The alignment challenge fwrite(&hdr[0], /* Wr hdr */ 1, 120, /* 120 bytes */ p_file); while (data == available) { BufFill(&buf[0], 512); fwrite(&buf[0], /* Wr data */ 1, 512, /* 512 bytes */ p_file); [...]} 5 What is the performance problem in the loop of this example?

The alignment challenge 6 Storage : 1 st sectorSector Buffer Read Application : 392 bytesSector Buffer Copy Storage : 1 st sectorSector Buffer Write Storage : 2 nd sectorSector Buffer Read Sector Buffer Copy Storage : 2 nd sectorSector Buffer Write Application : 120 bytes Write: 512 file offset 120

The alignment challenge High-level operations Write 120 bytes Write 512 bytes (looped) 7 Low-level operations Read 1 st sector Copy 120 bytes to buffer Write 1 st sector Read 1 st sector Copy 392 bytes to buffer Write 1 st sector Read 2 nd sector Copy 120 bytes to buffer Write 2 nd sector Each iteration in loop: 4 I/O operations

The alignment solution fwrite(&hdr[0], /* Wr hdr */ 1, 120, /* 120 bytes */ p_file); BufFill(&buf[0], 392); fwrite(&buf[0], /* Wr data */ 1, 392, /* 392 bytes */ p_file); while (data == available) { BufFill(&buf[0], 512); fwrite(&buf[0], /* Wr data */ 1, 512, /* 512 bytes */ p_file); } 8

The alignment solution 9 Application : 512 bytes Storage : Sector 1 Write Internal buffer not even used -> zero copy

The alignment solution High-level operations Write 512 bytes … 10 Low-level operations Write 2 nd sector from application buffer Write 3 rd sector from application buffer … Each iteration in the loop: 1 I/O operation

The alignment solution No matter how much resources we have… Unaligned transactions are costly The more limited the resources, the larger the overhead A desktop application might work without measurable impact, but an embedded system might be affected drastically! 11

Caching and buffering Caching/buffering mechanisms Data/Metadata caching File buffering 12

File buffering 13 Flush buffer to volume Write 1 Write 2 Write 3(a) Write 3(b) No write to volume

File buffering Characteristics Good to accumulate multiple small or frequent write transactions in a portion of a file. Good to prepare for multiple small or frequent read transactions in a portion of a file. Buffer length should be multiple of sector size to maintain good alignment. Metadata updates are deferred. 14

Caching Characteristics Good to improve frequent and relatively small random accesses. Costly in term of RAM and CPU usage. May have a negative impact on reliability. 15

Caching modes Cache ModeDescription ReadSectors cached upon read. Never cached upon write. Write-throughSectors cached upon read and write. Data on volume always updated upon write. Write-backSectors cached upon read and write. Data on volume manually updated upon write (or automatically on cache miss). 16

Volume caching sections 17 On a FAT: Cache for the FAT Cache for the directory entries Cache for the rest of the data section

Throughput For a high throughput : Align writes and reads to sector boundaries, Use buffers as large as possible (multiple of the sector size), Use cache and file buffering when appropriate. 18

File system failure Background: Most file systems are prone to corruption when an unexpected power failure happens. There are a few options to protect the file system or the data consistency. 19

File system corruption A file system is corrupted when its metadata is in an inconsistent state. Metadata can become inconsistent because transactions are not atomic and involve writing to multiple sectors. Metadata reliability is capital in preventing file system corruption. 20

File system corruption: ex Application FS Stack Device Write near EOF, growing file beyond cluster. Extend cluster chain Read-modify-write last sector Write sectors until EOC Write remaining in free cluster(s) Write data Read-modify-write FAT sector 1 Read-modify-write FAT sector 2 Update directory table Read-modify-write dir sector 0 (LFN)

File system corruption: ex Application FS Stack Device Write near EOF, growing file beyond cluster. Extend cluster chain Read-modify-write last sector Write sectors until EOC Write remaining in free cluster(s) Write data Read-modify-write FAT sector 1 Read-modify-write FAT sector 2 Update directory table Read-modify-write dir sector 0 (LFN) Partial data until old EOF Chain length mismatch Unbounded clus. chain Partial data (old EOF) Chain length mismatch Partial data (old EOF)

File system corruption: ex Application FS Stack Device Rename file to a longer name (LFN). Update directory table (LFN) Read-modify-write dir sector 0 Read-modify-write dir sector 1

File system corruption: ex Application FS Stack Device Rename file to a longer name (LFN). Update directory table (LFN) Read-modify-write dir sector 0 Read-modify-write dir sector 1 Orphaned entries Vanished entries Orphaned cluster chains

Fail safe solutions Battery backed-up systems Detect brown-out and allow enough time to finish a file system transaction on failure Transaction safe file systems Journaling Log-structured Copy-on-Write (CoW) 25

Journaling file systems Track changes to the file system Either complete or roll-back unfinished operations on failure recovery. Logical journals only protect metadata. Physical journals also protect file content. Both are costly in term of performance and resource usage. Most journaling systems assume atomic sector writes. 26

Transaction safe file systems Incorporate content and metadata safety in the core design of a file system. Copy-on-Write can help. Higher resource usage than traditional file systems. Limited compatibility with major OSes. 27