About garbage collection logic

RE: About garbage collection logic

takashina hiroki — Wed, 15 Apr 2020 01:57:37 GMT

>> This way we only do erasing the page once in a while (when doing GC) and limit the number of time an area in flash being erased.

I'm also asking about the number of times the flash is deleted with different tickets.
If you don't mind, can you answer to that as well?

https://devzone.nordicsemi.com/f/nordic-q-a/60069/number-of-times-flash-is-deleted-by-garbage-collection
https://devzone.nordicsemi.com/f/nordic-q-a/60073/how-to-calculate-flash-life-by-garbage-collection

RE: About garbage collection logic

takashina hiroki — Wed, 15 Apr 2020 01:48:22 GMT

What if the number of valid data records in ① and ② is larger than the size of the GC page?

Where does the GC page go?
Will they move one by one in the order of page numbers?

RE: About garbage collection logic

Hung Bui — Tue, 14 Apr 2020 15:16:06 GMT

Hi Takashina,

You can read more about the garbage collection (GC) here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_fds_functionality.html?cp=7_1_3_56_1_2#lib_fds_functionality_gc

Basically, the FDS system doesn't do the erasing (or updating) a record. It only marks the records as deleted (invalidated). When (1) and (2) are full (of both invalided and valid records) the PM_EVT_STORAGE_FULL is generated. The application will have to call fds_gc(). This is when GC started. It will start with erasing the GC's page. Then copying the valid records inside (1) and (2) to the GC page and use the GC as one of the valid page. It continue o all data page, from (1) to (2) and so on.
This way we only do erasing the page once in a while (when doing GC) and limit the number of time an area in flash being erased. The GC page is not fixed to a physical page in flash but move from one page to another (rotating) so that we don't have a the same page being used as GC page. If the page doesn't have any invalided record, it will not be GC hence doesn't get erased.