Lines Matching refs:sector

12 ZMS divides the memory space into sectors (minimum 2), and each sector is filled with key-value
18   starting from the bottom of the sector
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
22 are needed for the sector to describe its status (closed, open) and the current version of ZMS.
24 When the current sector is full we verify first that the following sector is empty, we garbage
25 collect the N+2 sector (where N is the current sector number) by moving the valid ATEs to the
26 N+1 empty sector, we erase the garbage collected sector and then we close the current sector by
28 Afterwards we move forward to the next sector and start writing entries again.
31 the first sector after garbage collecting it and erasing its content.
33 Composition of a sector
35 A sector is organized in this form (example with 3 sectors):
81 Definition of each element in the sector
84 ``Empty ATE:`` is written when erasing a sector (last position of the sector).
86 ``Close ATE:`` is written when closing a sector (second to last position of the sector).
88 ``GC_done ATE:`` is written to indicate that the next sector has been already garbage
89 collected. This ATE could be in any position of the sector.
114 		/** Storage system is split into sectors, each sector size must be multiple of
128 As ZMS has a fast-forward write mechanism, we must find the last sector and the last pointer of
130 It must look for a closed sector followed by an open one, then within the open sector, it finds
132 After that, it checks that the sector after this one is empty, or it will erase it.
139 If we must perform a write, then an ATE and Data (if not a delete) are written in the sector.
140 If the sector is full (cannot hold the current data + ATE) we have to move to the next sector,
141 garbage collect the sector after the newly opened one then erase it.
164 Each sector has a lead cycle counter which is a uin8_t that is used to validate all the other
168 Each time an ATE is moved from a sector to another it must get the cycle counter of the
169 destination sector.
170 To erase a sector, the cycle counter of the empty ATE is incremented and a single write of the
172 All the ATEs in that sector become invalid.
177 To close a sector a close ATE is added at the end of the sector and it must have the same cycle
179 When closing a sector, all the remaining space that has not been used is filled with garbage data
186 When calling a ZMS write, the current sector could be almost full and we need to trigger the GC
187 to switch to the next sector.
190 ZMS adds an API for the application to get the current remaining free space in a sector.
191 The application could then decide when needed to switch to the next sector if the current one is
192 almost full and of course it will trigger the garbage collection on the next sector.
205 		uint16_t len;      /* data len within sector */
210 				uint32_t offset; /* data offset within sector */
232 For both scenarios ZMS should always have an empty sector to be able to perform the
235 Key-value pairs and keep one sector empty to be able to launch GC.
236 The empty sector will rotate between the 4 sectors in the partition.
238 .. note:: The maximum single data length that could be written at once in a sector is 64K
245 at the top of the sector.
257 ``SECTOR_SIZE:`` Size of the sector
268 Large data values ( > 8 bytes) are stored separately at the top of the sector.
271 16 bytes of ATE must be added at the bottom of the sector.
291 It also guarantees that every memory location is written only once for each cycle of sector write.
293 As an example, to erase a 4096 bytes sector on a non-erasable device using NVS, 256 flash writes
298 is moving some blocks from one sector to another.
318 As we have 944 bytes available for ATEs for each sector, and because ZMS is a fast-forward
319 storage system, we are going to rewrite the first location of the first sector after
345 ``SECTOR_EFFECTIVE_SIZE``: is the size sector - header_size(80 bytes)
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)
401 - For devices with large write_block_size and/or needs a sector size that is different than the
430 - The size of a sector needs to be dimensioned to hold the maximum data length that will be stored.
431   Increasing the size of a sector will slow down the garbage collection operation which will