EEPROMClass::begin(4096) truncate size fails when previously set to 8Kb

[Nagymadar]

I have tried to set the EEPROM size to 8K, but failed. I guess it is maximized to 4K?

Nevertheless when I set to 4K again, EEPROM.begin(4096) failed to truncate it back from 8K->4K.

In EEPROM.cpp:
bool EEPROMClass::begin(size_t size)

It tries to truncate, but these functions fail with ESP_ERR_NVS_NOT_ENOUGH_SPACE:
nvs_get_blob(_handle, _name, key_data, &key_size);
nvs_set_blob(_handle, _name, key_data, size);
nvs_commit(_handle);

I had to erase the whole chip as workaround. But I think truncate should have worked.

[lbernstone]

Your NVS partition is out of space. Read through #4551 to see how to use a custom partitions.csv to increase the size of your nvs.
Also, if you don't need compatibility with Arduino, then use the Preferences library instead of EEPROM.

[Nagymadar]

I am not getting it, the nvs is 20Kb. What is the overhead/limitation of EEPROM to use the most of the nvs?

Preferences library is a good hint, thanks. I try it, but have to check init time. I used to use SIPFF, but takes 0.5sec to init at boot, what was slow for my needs.

[lbernstone]

EEPROM is using NVS, so Preferences can't be any longer to init than that.
When you reallocate an entry in nvs, it is not going to reclaim the existing space until complete, so when you go from 8k to 4k, it will use 12k. The system is also using about 8k, so you are running out of space. Reallocating is not something I would ever recommend to do in a production environment. Make it as big as you would ever need, and leave it as such. Note that the EEPROM in esp32 is far more flexible than any other version. If you really want to know more, the docs are here
Preferences will be much more efficient about your "disk" usage than EEPROM.

[Nagymadar]

Thanks a lot. Makes sense now.

I tested Preferences library. Init is super fast (<1ms) in comparison with SPIFFS (~500ms). putString also fast, 1-2ms.

If I understand EEPROM, it opens a 4K blob, copies to memory. Commit stores the whole 4K to NVS. That sounds a lot slower than using separate namespaces and keys.

[lbernstone]

Preferences will also be able to take advantage of the lazy nature of the flash. This means that if you are writing just a few bytes to a key entry, it will find empty space, write those few bytes and update the index to point at the new data. No erases needed. Writing to EEPROM, particularly if it is 4096+ bytes, will require a write of the whole sector(s), and at least one erase.
Please close the issue if you are satisfied.

[Nagymadar]

Thanks for the lot of info. Learnt a lot.