Lines Matching +full:verify +full:- +full:formatting
5 Zephyr Memory Storage is a new key-value storage system that is designed to work with all types
6 of non-volatile storage technologies. It supports classical on-chip NOR flash as well as new
12 ZMS divides the memory space into sectors (minimum 2), and each sector is filled with key-value
15 The key-value pair is divided into two parts:
17 - The key part is written in an ATE (Allocation Table Entry) called "ID-ATE" which is stored
19 - The value part is defined as "DATA" and is stored raw starting from the top of the sector
21 Additionally, for each sector we store at the last positions Header-ATEs which are ATEs that
24 When the current sector is full we verify first that the following sector is empty, we garbage
37 .. list-table::
39 :header-rows: 1
41 * - Sector 0 (closed)
42 - Sector 1 (open)
43 - Sector 2 (empty)
44 * - Data_a0
45 - Data_b0
46 - Data_c0
47 * - Data_a1
48 - Data_b1
49 - Data_c1
50 * - Data_a2
51 - Data_b2
52 - Data_c2
53 * - GC_done
54 - .
55 - .
56 * - .
57 - .
58 - .
59 * - .
60 - .
61 - .
62 * - .
63 - ATE_b2
64 - ATE_c2
65 * - ATE_a2
66 - ATE_b1
67 - ATE_c1
68 * - ATE_a1
69 - ATE_b0
70 - ATE_c0
71 * - ATE_a0
72 - GC_done
73 - GC_done
74 * - Close (cyc=1)
75 - Close (cyc=1)
76 - Close (cyc=1)
77 * - Empty (cyc=1)
78 - Empty (cyc=2)
79 - Empty (cyc=2)
91 ``ID-ATE:`` are entries that contain a 32 bits Key and describe where the data is stored, its
94 ``Data:`` is the actual value associated to the ID-ATE
108 .. code-block:: c
115 * erase-blocks if the device has erase capabilities
128 As ZMS has a fast-forward write mechanism, we must find the last sector and the last pointer of
134 ZMS ID-Data write
200 .. code-block:: c
204 uint8_t cycle_cnt; /* cycle counter for non-erasable devices */
227 .. _free-space:
229 Available space for user data (key-value pairs)
235 Key-value pairs and keep one sector empty to be able to launch GC.
251 \small\frac{(NUM\_SECTORS - 1) \times (SECTOR\_SIZE - (5 \times ATE\_SIZE))}{2}
277 Each Key-value pair needs an extra 16 bytes for ATE which makes it possible to store 11 pairs
281 .. _wear-leveling:
287 Using storage systems that rely on an erase-value (NVS as an example) will need to emulate the
293 As an example, to erase a 4096 bytes sector on a non-erasable device using NVS, 256 flash writes
294 must be performed (supposing that write-block-size=16 bytes), while using ZMS only 1 write of
303 See :ref:`free-space`.
311 memory cells cannot be overwritten) and for non-erasable storage devices memory cells can be
318 As we have 944 bytes available for ATEs for each sector, and because ZMS is a fast-forward
345 ``SECTOR_EFFECTIVE_SIZE``: is the size sector - header_size(80 bytes)
364 --------
365 - Supports non-erasable devices (only one write operation to erase a sector)
366 - Supports large partition size and sector size (64 bits address space)
367 - Supports 32-bit IDs to store ID/Value pairs
368 - Small sized data ( <= 8 bytes) are stored in the ATE itself
369 - Built-in Data CRC32 (included in the ATE)
370 - Versioning of ZMS (to handle future evolution)
371 - Supports large write-block-size (Only for platforms that need this)
376 - Add multiple format ATE support to be able to use ZMS with different ATE formats that satisfies
378 - Add the possibility to skip garbage collector for some application usage where ID/value pairs
381 - Divide IDs into namespaces and allocate IDs on demand from application to handle collisions
383 - Add the possibility to retrieve the wear out value of the device based on the cycle count value
384 - Add a recovery function that can recover a storage partition if something went wrong
385 - Add a library/application to allow migration from NVS entries to ZMS entries
386 - Add the possibility to force formatting the storage partition to the ZMS format if something
392 but simpler, non-hierarchical ones).
398 - If you are using a non-erasable technology device like RRAM or MRAM, :ref:`ZMS <zms_api>` is defi…
401 - For devices with large write_block_size and/or needs a sector size that is different than the
404 - For classical flash technology devices, :ref:`NVS <nvs_api>` is recommended as it has low footpri…
408 - If your application needs more than 64K IDs for storage, :ref:`ZMS <zms_api>` is recommended here…
409 has a 32-bit ID field.
410 - If your application is working in a FIFO mode (First-in First-out) then :ref:`FCB <fcb_api>` is
416 life expectancy of the device described in this section: :ref:`wear-leveling`.
424 - The total size of the storage partition should be well dimensioned to achieve the best
427 in the documentation. See :ref:`free-space`.
428 We recommend choosing a storage partition that can hold double the size of the key-value pairs
430 - The size of a sector needs to be dimensioned to hold the maximum data length that will be stored.
435 - For some subsystems like :ref:`Settings <settings_api>`, all path-value pairs are split into two …
437 - Using small data to store in the ZMS entries can increase the performance, as this data is
445 - When using ZMS API directly, the recommended cache size should be, at least, equal to
447 - Each additional cache entry will add 8 bytes to your RAM usage. Cache size should be carefully
449 - If you use ZMS through :ref:`Settings <settings_api>`, you have to take into account that each Se…
456 A sample of how ZMS can be used is supplied in :zephyr:code-sample:`zms`.