Discussion
Today I'll study LittleFS's `lfs_format()` routine, and tomorrow I hope to study the rest. Glossing over any code that's shared. This `lfs_format()` routine, among other things, is only compiled if a compiletime flag indicates you're happy with a read-only filesystem.
The top-level routine intended to be invoked by external code possibly transiently (depending on macros) invokes a method to grab a lock & performs the core logic with possible logging both before & after (depending on macros).
1
That init routine remembers the given config & some of its data in particular, performs various validation, statically or dynamically allocates a read cache followed by a program cache, zeroes out those caches via another helper, statically or dynamically allocates a readahead buffer, remembers & validates certain properties from the config, & cleans up after any errors.
And I didn't mention the error recovery codepath, at which point the caches are freed.
3/4?
LittleFS includes a memory allocator for "blocks" of the harddrive. This allocator might check the lookahead buffer iterating over it until it finds a free block. Or it might error out upon seeing that everything has been allocated. Or it invokes a helper which resets the lookahead buffer, carefully recurses over the filesystem in 2 passes to check which blocks are free.
The allocator repeatedly all these approaches until success or failure.
4/5!
There's a routine for reading from the harddrive which validates its inputs, checks the program & read caches for the requested data, invokes a read() method on the remembered context either into the cache or the caller's memory, & repeats until it has read all the requested data.
4.5/4.5 Fin for today! Writing directory data is quite involved, so I'll cover that tomorrow!
Install bonfire.cafe
Get the full app experience
That core routine invokes a shared helper to init the LittleFS filesystem, validates that there's a non-zero blockcount, zeroes out the lookahead buffer, updates the lookahead checkpoint property via another helper, invokes a helper to (via yet more helpers) allocate 2 harddrive blocks & read/update those allocated blocks, inits a superblock including (via a helper) a hardcoded or configured version number fixing (via helpers) endianness, writes to harddrive twice, & reads it.
2/4?