What we're running into at my work:

large external flash partitioned with "best guess" which turned out to be way wrong 6 years later. migrating partitions is not fun.

External storage must be encrypted, verified, and unique. So someone can't take the external flash off one device and solder it to a target device. Which means synchronizing between internal nvstorage and external

Large ( multiple page size writes/reads/erasures ) take 100s of ms. The drivers (again, written 6 years ago) assume that no one would ever want to interrupt those writes.

What we ended up with is a stack of tech with some nasty tradeoffs. I think the only off-the-shelf software is the encryption and serialization. The rest is custom (which had to be thrown out when changing RTOSes), built on assumptions by non-domain experts

It's one of those things that every embedded dev kind of cobbles together on their own as they discover the limit of struct arrays stored in EEPROM.

Except this one actually seems worse in some ways, because to find a file you have to keep following what is effectively a single linked list of file headers until you find the file you need.

The authors even acknowledge this is just a copy of tar's approach, and even acknowledge that that was in turn done this way due to a lack of random seeking on tape systems at the time. But a microcontroller's EEPROM/SPI/... data is nothing like this? You can just do arbitrary seeks. So I'm not sure what they were going for here.

The implementation is also full of obvious bugs that will cause crashes or hangs or worse when operating on an untrusted or simply just corrupted filesystem: https://github.com/clisystems/utfs/blob/5f1a6f049a0ca5435afb...