Introduction

A file system is a method and data structure that an OS uses to control how data is stored and retrieved. By separating the data into pieces and giving each piece a name, the data is easily isolated and identified. Taking its name from the way a paper-based data management system is named, each group of data is called a ‘file’.

File systems for embedded systems have additional requirements:

1. Power-cut resilience - We need a guarantee that the data won’t become corrupted
2. Wear-levelling - The system should make use of the entire storage device (i.e. it shouldn’t just read/write to a few blocks of memory)
3. Tiny footprint - We’re constrained by ROM and RAM.

At the moment, our external memory will consist of a microSD card and FRAM (‣).

• We won’t need a file system for FRAM because it’s small, so we can follow a predefined arrangement managed by the compiler and the source code.
• We should use a file system, like Reliance Edge, for our bulk storage (SD/eMMC/NAND Flash). FAT file systems are also used a lot for SD Cards, but Reliance Edge may be better.

Examples

LittleFS

LittleFS is used by ACubeSat.

Description

From ACubeSat documentation:

• LittleFS, in specific, is a block-based, power-loss-resistant, low footprint filesystem designed specifically for use in flash memory.
• It supports all POSIX file operators (e.g. open(), write()) while providing useful reliability capabilities.
• Furthermore, RAM usage is strictly bounded and configurable at compile time to prevent memory overflows.
• LittleFS operations are considered safe even in the event of a random power loss, as it is designed based on log and COW structures and guarantees the availability of a last known state to fall back to.