File Systems in Real-Time Embedded Applications

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

2. 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.

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

4. 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

5. 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); [...]} What is the performance problem in the loop of this example?

6. The alignment challenge Write: 512 bytes @ file offset 120 Read Sector Buffer Storage : 1stsector Copy Sector Buffer Application : 392 bytes Write Sector Buffer Storage : 1stsector Read Sector Buffer Storage : 2ndsector Copy Application : 120 bytes Sector Buffer Write Sector Buffer Storage : 2ndsector

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

8. 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); }

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

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

11. 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!

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

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

14. 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.

15. 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.

16. Caching modes

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

18. 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.

19. 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.

20. 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.

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

22. File system corruption: ex. 1 Application FS Stack Device Write near EOF, growing file beyond cluster. Read-modify-write last sector Write data Write sectors until EOC Write remaining in free cluster(s) Read-modify-write FAT sector 1 Extend cluster chain 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)

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

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

25. 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)

26. 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.

27. 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.