MDB_MAP_FULL error writing table to storage

@Max Thanks for that update. We’ll do some destructive testing to understand what that means for us.

Another angle has come up. I’m happy to address it elsewhere if that’s better…

Only one of our four Ezlo Plus has taken up the version update to firmware 2.0.30 automatically. Per, the other 3 are still on 2.0.29. I’d happily check also by logging into the controller, but while I’ve looked at many files in /etc with various version numbers, none hold the version number of the firmware. Maybe you could point me in the right direction and also suggest what might be going on with the boxes not updating. I really don’t want to fix this symptomatically, but to get at the root cause!

While we see an increase in capacity, it’s strangely short of what we would expect, and we are now getting a different error message.

We would really appreciate documentation and tools to form deeper insights about what’s going on.

After updating to your newest firmware, testing shows we’re able to store 3.5-7x more items of data than before. The file /home/data/storage.bin which I think is where it is stored, is now about 3.5MB.

We are primarily storing a single large Lua array that can now hold about 710 items before failing. A maximal entry is around 900 bytes, based on inspection of storage.bin. So we can account for about 650K of the 3.5MB footprint of storage.bin.

We no longer see MDB_MAP_FULL but instead:
Fatal error: DbLuaBinding: storage.setTable: fail to set a table value

When this happens, we remove the oldest event in the array and try saving again. The total size currently hovers around 710 entries.

Can you help us understand what’s going on?

The storage bin is open in 154 simultaneous file descriptors. I don’t even know whether that’s a smell, but I thought I’d mention it.
/tmp/log/firmware# lsof | grep /home/data/storage.bin$ | wc
154 1602 16786