Why SPIFFS over LittleFS?

[robertlipe]

More awkward questions...

I'd only really heard of ARM's LittleFS in recent years prior to this project, but NDS uses the older SPIFFS. The User APIs are almost identical and our entire touch surface is tiny - around seven files.

I know we're not (primarily) 8266, but if https://arduino-esp8266.readthedocs.io/en/latest/filesystem.html#spiffs-deprecation-warning is to be believed, we should consider moving. One consideration is how important it is to preserve existing data.

As counterpoint, the ESP32 doc seems slow in picking up this recommendation, but looking at the SPIFFS GitHub page, it's pretty clear that SPIFFS is closed for business.

How married is this project to spiffs? Was it just a default choice when LittleFS was still young?

If we were to change, how important are the effects.cfg files? Should we ship with both and convert over time? (I have No Idea how we'd handle repartitioning in that case....but if we have a long-term need, we could split them on one boot and then reclaim the space on the next boot.) Does this project consider blowing away that file on an update OK? I'm not thrilled with tossing that around casually, but I don't know how many people customize effects and expect them to be preserved. (I think they were just silently broken by the recent ping-pong partitions CL anyway.) My gut says that excessive cleverness to retain the effects you'd turned off and your device's current index into that array is probably just not worth it. Webserver files would just get recreated, of course.

I don't mind looking at it if that's appropriate & wanted. It just bubbled up when I was looking at dynamic partition tables for those "big" 16MB configurations.

Prevailing wisdom seems to be that SPIFFS is more likely to eat data (eek!) but LittleFS has "real" directories and better journaling, but at a higher per-file cost. (We're not exactly running enterprise-ready Apache instances...) LittleFS doesn't mangle binary objects that contain a "\n" to be "\n\r", which seems pretty darned important.

[rbergen]

I think SPIFFS was chosen because it was the obvious choice at the time - I believe the first lines of code in this repo were written in 2017.
I've looked at the LittleFS thing myself before, and I concluded that there is currently no urgent need to migrate from one FS to the other, based on the principle of "if it ain't broken, don't try to fix it". At the moment, SPIFFS is not broken for NightDriverStrip, nor was it when we did store binary files on the FS.

At the same time, we're not married to SPIFFS either. If there is a reason to move away from it, we can.

Losing effects.cfg (and device.cfg, and current.cfg) isn't lethal in any way - the code knows it can happen that they're not there. However, losing them can be annoying for a user, based on what changes they made. If we were to move from SPIFFS to LittleFS, I would therefore plead for implementing code to migrate any files files that are present.

In my personal flavor of pseudo code, to be executed early in main.cpp setup():

if (mounting the data partition as SPIFFS is successful)
    read effects.cfg, device.cfg and current.cfg, if present
    unmount the data partition
end if

mount the data partition as LittleFS, and format it in case of initial failure
write any .cfg files that were read from SPIFFS
...

The actual code would obviously be a little more involved, but I think not so much that we'd burn an unacceptable amount of firmware bytes on implementing it.