SPIFFS file access slow on 16/14M flash config

[TD-er]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: [ESP-12]
• Core Version: [c0eb301] (core 2.6.0 SDK 2.2.2)
• Development Env: [Platformio]
• Operating System: [Windows]

Settings in IDE

• Module: [Generic ESP8266 Module|Wemos D1 mini pro]
• Flash Mode: [dio]
• Flash Size: [16MB]
• lwip Variant: [v2 Lower Memory_low_flash]
• Reset Method: [nodemcu|manual]
• Flash Frequency: [40Mhz]
• CPU Frequency: [80Mhz]
• Upload Using: [OTA|SERIAL] (both)
• Upload Speed: [115200] (serial upload only)

Problem Description

Open file from SPIFFS is quite a bit slower when using 16M/14M flash layout, compared to the same code running on the same node with 4M/1M as flash layout.

I am running a test setup on ESPeasy using the full 16M flash and thus 14M SPIFFS (want to keep using OTA).
Serving any web page is notably slower (1.7 sec compared to 300 msec).
After some debugging, it became clear that opening files from the SPIFFS was taking a lot longer.

Description	Function	#calls	call/sec	min (ms)	Avg (ms)	max (ms)
Load File 4M		16712	2.40	1.139	3.167	23.190
Load File 16M		8	0.01	1.329	93.900	248.736

And indeed, I do some checks for files on the SPIFFS while serving the web pages.
These checks are not really that efficient (try open instead of check first if it exists), so I will change that.

But still the access times to the SPIFFS are significantly slower when using 16M flash.
In PlatformIO I use:

board                     = esp12e
build_flags               = -Wl,-Tesp8266.flash.16m14m.ld

This behaves the same when using board = d1_mini_pro as suggested here

These are the detected flash settings:

Param	value
Flash Chip ID:	Vendor: 0xEF Device: 0x4018
Flash Chip Real Size:	16384 kB
Flash IDE Size:	16384 kB
Flash IDE Speed:	40 MHz
Flash IDE Mode:	DIO
Flash Writes:	6 daily / 6 boot
Sketch Size:	946 kB (1100 kB free)
SPIFFS Size:	13579 kB (13504 kB free)
Page size:	256
Block size:	8192
Number of blocks:	1697
Maximum open files:	5
Maximum path length:	32

It is apparently using these settings:

Arduino/tools/sdk/ld/eagle.flash.16m14m.ld

Lines 17 to 20 in 3877914

	PROVIDE ( _SPIFFS_start = 0x40400000 );
	PROVIDE ( _SPIFFS_end = 0x411FB000 );
	PROVIDE ( _SPIFFS_page = 0x100 );
	PROVIDE ( _SPIFFS_block = 0x2000 );

I have not yet tested to see if performance improves when increasing the block size.
Increasing SPIFFS_MAX_OPEN_FILES to 20 doesn't seem to make any difference. (was hoping the FD cache would also increase)

Or maybe any other tweak suggestions here?

[d-a-v]

It may be time for LittleFS ?

[TD-er]

@d-a-v I guess so, but for the project I meant to use it for I have to make a choice on file system in the next few weeks. (2 months at most)
I see that it is still in development for this framework. What is its current status?
And how do I build it myself?

[TD-er]

Does anyone have a suggestion how I can increase the block size of this partition layout?
I've been messing with this for way too long already and it keeps on resetting when I try to reduce the number of blocks.

In eagle.flash.16m14m.ld I changed the following lines:

PROVIDE ( _SPIFFS_end = 0x411F8000 );  <=== Lowered to get a integer multiple of block size
PROVIDE ( _SPIFFS_block = 0x8000 );

Original is:

Arduino/tools/sdk/ld/eagle.flash.16m14m.ld

Lines 17 to 20 in 68c0a1c

	PROVIDE ( _SPIFFS_start = 0x40400000 );
	PROVIDE ( _SPIFFS_end = 0x411FB000 );
	PROVIDE ( _SPIFFS_page = 0x100 );
	PROVIDE ( _SPIFFS_block = 0x2000 );

[devyte]

The slowness you describe is known and reported in #2581 . However, I'll keep this open to address the specifics of performance, given that the other thread has grown too long.
I think you're on the right track: the slowness is most likely due to the huge size without adjusting page and block sizes. The underlying search algorithms are naive and I think do linear search over all blocks.
It is one of the things pending to investigate and optimize these parameters for the bigger SPIFFS sizes. So no, no suggestions, because what you're doing is exactly what needs to be investigated.
The parameters should allow sane values, but I'm not sure of the implications of having e.g. a block size bigger than a flash sector size. There might be changes required to how a SPIFFS block is written to flash, I.e. write multiple 4KB sectors instead of just a single write attempt. I don't really know, that's just a WAG. One thing you could test isthe go smaller to checkthe if it crashes, and test if 4KB is a threshold.
SPIFFS is widely used in many projects at its lower api level, so there are a lot of examples out there. If you figure this out, it will be a huge help to finalize the support for pro boards.
About LittleFS, I don't think it's a direct replacement, at least not in its current form, and not for all cases. At the very least, its wear leveling is not up to par with SPIFFS. It does seem to perform better, though, but again, the SPIFFS parameters haven't been ever fine tuned for performance.

[TD-er]

I have tried several builds myself but keep running into crash/reboot loops when trying to set the block size to 32kB.
So I will stop trying for now unless someone can point me to the right direction where I can find some documentation on how it should be done.

For my own project, I will try to use the left over 12 MB of flash (using the 4M/1M config) as a single circular buffer and thus also avoid any other SPIFFS issue I may run into.

[devyte]

How about testing with bigger page size in the meantime? The impact of page size is also not known.

[devyte]

The underlying SPIFFS lib isn't ours, it comes from here:
https://github.com/pellepl/spiffs

Docs are in their wiki.
For our integration code, there are no docs, just some code comments.

[TD-er]

The .ld files are also from the spiffs project?

[bill-orange]

@d-a-v Can you use FTP with Little FS in the usual fashion?

[d-a-v]

@bill-orange
This is a question for @earlephilhower. The answer is yes. Thanks to his recent work, every library using FS::or SPIFFS. can be used on SPIFFS, SDFS and also faster LITTLEFS to come with little-to-no changes.

[earlephilhower]

@bill-orange you can probably run the same FTP server library,. but if it hardcodes SPIFFS.open you'll need to replace with LittleFS.open to ensure the right FS is used. You'd also need to upload your files on chip with the LittleFS uploader if it's a FTP server.

[earlephilhower]

@TD-er, I don't have a 16M board but would be interested in hoe LittleFS V2 works with it and the settings used. Would you be able to run your testing w/LittleFS instead and report some results? We kind of assume it'll be better than SPIFFS, but hard data is way better...