Embedded as in &quot;32-bit ARM running Linux&quot;, or &quot;8-bit microcontroller&quot;? Either way, as someone who has written a FAT driver for embedded systems in the later category, that looks like it&#x27;s far more code than it needs to be. Full read&#x2F;write functionality can be done in approximately 800 (Z80) machine instructions. FAT is a linked list, and if you look at it that way, it doesn&#x27;t take much code to manipulate one.<p>I&#x27;ve written a bit more about that before:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7492318" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7492318</a><p>Append = find an empty cluster and link it into the chain for the file, then write into it. Create is similar except you start with a empty chain and also add an entry to the directory (which is like writing&#x2F;appending to a file, because directories are files.)<p>When allocating next clusters you can reduce fragmentation significantly over the dumb &quot;first fit&quot; strategy if you scan the FAT to find contiguous free clusters and apply a next&#x2F;best&#x2F;worst fit. Even better if you add an API to allow tuning the amount of &quot;gap&quot; after a file when creating it, based on knowledge of how much it may expand in the future.<p>I believe that with good tuning and allocation heuristics, FAT32 can outperform the far more complex filesystems (ext*, NTFS, etc.) widely believed to be superior. One idea I&#x27;ve never gotten around to testing out is to modify the Linux FAT driver and do some benchmarking.