geky
commented
8 months ago Hi @hattesen, littlefs does have a couple cases where latency can spike. And to make things worse these latency spikes could be described as "extreme" due to poor scalability. This is something I'm working on improving[^1][^2] but it's how things are right now.
Causes of latency spikes:
-
Metadata Compaction
littlefs stores metadata in append-only logs that need to be periodically compacted. This scales $O(B^2)$ where $B$ is the configured block size.
In theory you can decrease the compaction overhead by decreasing the block size, but this is of course limited by the block device's physical geometry.
As a temporary workaround for scalability issues,
metadata_maxwas added, which artificially limits how big metadata logs can get before being split.metadata_maxcan improve compaction overhead, but comes at a storage cost. -
Block allocation scans
littlefs doesn't know exactly when blocks go out of scope. To know what blocks can be safely allocated, littlefs periodically scans the filesystem to populate a RAM-backed bitmap of known unused blocks called the "lookahead buffer". This scales $O(F)$ where $F$ is the size of the filesystem.
You can decrease how often this scan needs to be done by increasing the size of the lookahead buffer. But this comes at a RAM cost, which runs counter to the goals of littlefs.
Note: Even if the lookahead buffer contains the entire block device, littlefs still needs to periodically scan to update its knowledge of what blocks are unused.
You can also decrease the cost of this scan by increasing the block size. Larger blocks means fewer blocks for a given filesystem. Unfortunately this makes write granularity worse and increases metadata compaction overhead.
Q2: Is there any type of housekeeping that can be performed by an idle-loop task to reduce the worst-case write-latency of littlefs?
This is the intention of the recently added lfs_fs_gc function. Calling lfs_fs_gc in your idle loop should move high latency tasks there as much as is currently possible.
Currently lfs_fs_gc only performs the block allocation scan, improving block allocation latency. It doesn't improve the metadata compaction latency yet. But the plan is to add any future janitorial work to this function.
[^1]: There is a new metadata data-structure in the works that should be able to reduce compaction overhead from $O(B^2)$ down to $O(B\log{B})$. [^2]: There is a plan to add an optional disk-backed block map that should remove the block allocation scan completely.
hattesen
I have a large number of projects that use littlefs for storing configuration and logging.
Some projects use internal NAND flash, others use external (QSPI) NOR flash for storage.
Keeping worst-case write latency to a minimum will minimize the risk of buffer overruns and resulting data corruption.
Q1 In littlefs, what are the (normally occurring) situations that result in high latency during write operations?
Q2 Are there any general recommendations on how to reduce worst-case write latency in littlefs?
Q2: Is there any type of housekeeping that can be performed by an idle-loop task to reduce the worst-case write-latency of littlefs?
Thank you in advance for any guidance in this matter.
PS: I am in the process of building a USB MTP (Media Transfer Protocol) device handler for TinyUSB, allowing a "live" littlefs file system to be accessed by a USB host without risking file system corruption associated with accessing a "live" (FAT) file system using a USB MSD (Mass Storage Device) connection. It will provide great benefits allowing dynamically updating configuration files, downloading log files etc, completely transparently, from any USB Host (Although MacOS will need an MTP driver, as their default implementation is restricted to downloading photos and videos).