[Answered] NVS: Is there any form of storage management?
[Answered] NVS: Is there any form of storage management?
Got to thinking about NVS (Non Volatile Storage) management today. Is the space within managed in a fashion that if I wish to store a blob of 1000 bytes but there isn't a contiguous area for that 1000 bytes but there ARE two separate of areas of 750 bytes each ... will there be a re-arrangement of items and my request be satisfied or will the request fail?
Last edited by kolban on Sat Nov 26, 2016 5:18 am, edited 1 time in total.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: NVS: Is there any form of storage management?
NVS documentation has an implementation details section which I believe has an answer to this question.
Each NVS page is either empty, active, or full (disregarding possible 'invalid' state for now). One one page is in 'active' state at a time, and that is the page where new items will be written to. If there is not enough space in the active page to store a new item, then the page is marked 'full' and new empty page is requested. So if the active page has just 11 unused entries left (32 byte each, enough to store a blob of 320 bytes, one entry is used for metadata), and you try to write 400 byte blob, the page will be marked full and the write will go into a new page.
It may sound like a waste of space (and it is), but it greatly simplifies fault recovery algorithm (handling of cases when power went out in the middle of a write). Also NVS was mainly designed to store integer values and short strings. While we are using NVS right now to store RF calibration data blob (which is almost 2k long), it's somewhat of an edge case and something that we are planning to fix after 1.0.
It is also possible to implement "defragmentation" algorithm to collect all used items in a near-optimal way. I'll put this on the list of improvements that need to happen for NVS.
Each NVS page is either empty, active, or full (disregarding possible 'invalid' state for now). One one page is in 'active' state at a time, and that is the page where new items will be written to. If there is not enough space in the active page to store a new item, then the page is marked 'full' and new empty page is requested. So if the active page has just 11 unused entries left (32 byte each, enough to store a blob of 320 bytes, one entry is used for metadata), and you try to write 400 byte blob, the page will be marked full and the write will go into a new page.
It may sound like a waste of space (and it is), but it greatly simplifies fault recovery algorithm (handling of cases when power went out in the middle of a write). Also NVS was mainly designed to store integer values and short strings. While we are using NVS right now to store RF calibration data blob (which is almost 2k long), it's somewhat of an edge case and something that we are planning to fix after 1.0.
It is also possible to implement "defragmentation" algorithm to collect all used items in a near-optimal way. I'll put this on the list of improvements that need to happen for NVS.
Who is online
Users browsing this forum: Baidu [Spider], markkuk and 349 guests