Mail me or post an issue on github if you want answers here.

###Q: Why is spiffs so slow?# A: Apart from the underlying hardware (CPU and SPI flash), it is mainly because spiffs uses little memory. Spiffs does not build any file-trees in ram or such, it is really more of a brute-force file system. One may enable caches and stuff, but it will probably still be pretty slow. The slowest part of spiffs is the file system integrity check, SPIFFS_check. This is because checking must cross-reference huge parts of information using just a handful of bytes. Hence, it runs several scans over the full file system. That said, a lot of effort has been put into optimizing spiffs, it should not be slower than it must to be.

###Q: How does spiffs handle powerlosses?# A: There is a scheme for updating data: when modifying a page the old page is first marked as being modified, then the new page is written with the updated (and possibly not updated) data. Then the old page is removed, and finally the new page is marked as finalized. In event of a power loss somewhere, there might be two pages with same id, but the status of these pages will indicate which one is valid. There also are certain integrity tests that always are tested when accessing files. If the problem can be mended, there will be an attempt to do this if possible. In the early days of spiffs, a full integrity check was made at mount time, but I removed this as it took so long time. It must now be invoked by user. This integrity check will remove such duplicate pages mentioned before and try to fix a bunch of other problems that might arise from power losses.