FDS wear-leveling not working

[Adrian Eggenberger]

Hi

I've just done a few tests with the FDS system of the SDK12.2. My observation is, that the FDS doesn't properly use all assigned flash pages to reach a maximal lifetime.

I have a configuration with the space for the FDS is set to 4 pages. The FDS will use one page as SWAP and the other three pages as DATA pages. My code is writting approximatly 30 records a ~30Bytes to the FDS and randomly updates these records. Once one page is nearly full the garbage collector copies the valid data to the SWAP page and converts the previous SWAP page into a DATA page and the erased page becomes the new SWAP page. Once the new data page is nearly full the valid records are copied back to the SWAP page and so on. In fact only two of the four pages are used.

In my opinion a good flash manager should use all assigned flash pages to reach the maximal possible lifetime. This will allow the developer to add more space to the FDS to increase lifetime.

The problem is based in the fds.c in the function "write_space_reserve" this function always starts at the same position in the flash page list.

Any thoughts how this could be improved?

Adrian

[emdi]

Hi,

if you run garbage collection when the flash is full then the swap page will be moved around as you would expect and wear leveling will be maximized.

[Hung Bui]

The main point of doing a gc in our implementation is to rearrange the records in the page to make biggest free space on the same page. Not to have more free empty page. We try to keep the complexity at low level.

There is one small risk with your approach is to keep track of the moving process, how to recover when there is a power failure occur when gc is happening, to avoid duplicated data ?

From our point of view gc should only be called when the flash is nearly full (using fds_stat) this to make sure wear leveling will be effective and to avoid unnecessary flash activity. But I do agree this can be an issue if there are lots of data coming and we need to be quick to store them before overloading the RAM. We don't want to do gc at that point. But this can be avoided by checking with fds_stat.