• State Verified Answer
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 1388 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 245594
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

fds_gc() does not skip pages after first usage of FDS

Elias

I'm trying to debug issues in my application related to FDS garbage collection.

My application periodically runs fds_gc() from startup. At this point, garbage collection is doing nothing. However, after I call pm_peer_rank_highest() once, fds_gc() appears to garbage-collect the page each time it is run. Adding some debug output to nrf_fstorage_erase(), I see that it is called after every fds_gc() after pm_peer_rank_highest(), and never before. Digging into fds.c, I see where m_pages[].can_gc is set to 'true', but I don't see where it is set to 'false'. Is this a bug?

I'm using nRF SDK 14.2, with Peer Manager and FDS modules backported from SDK 16.

  • +1

    Hi,

    Thank you for reporting. It seems you are right that this is a bug. Referring to FDS from SDK 16, m_pages[page].can_gc is set to true on line 830 and 958 in fds.c. It is is also set on line 722, by the call to page_scan() if a dirty record exists, but it is never set to false. I have reported it to the SDK team.

    I do not see this as a major bug though, and it should not have any significant consequences. 

  • 0 in reply to Einar Thorsrud

    The consequence I was worried about was flash wear. I originally planned to have fds_gc() run once per minute, but this will go through the 10,000 write-erase cycles for flash in just under a week. Will this thread be updated once a fix is developed?

  • 0 in reply to Elias

    Hi,

    Elias said:
    The consequence I was worried about was flash wear. I originally planned to have fds_gc() run once per minute, but this will go through the 10,000 write-erase cycles for flash in just under a week

    To be honest I did not think of running GC that often. Why do you want to do that? Typically we recomend do run it when you get FDS_ERR_NO_SPACE_IN_FLASH returned when writing of updating a record (also if you get NRF_ERROR_STORAGE_FULL returned from certain peer manager calls, which uses FDS). This minimizes the number of garbage collection runs, saving power and reducing flash wear.

    Update: If you do not want to wait for the FDS to be full before doing GC, you can check the amount of free space using fds_stat() regularly, and make a desition on wheater to do GC based on that.

    Elias said:
    Will this thread be updated once a fix is developed?

    I cannot promise that this will be part of the next nRF5 SDK release, so it might take some time. I will try to remember updating this thread if/when it happens, though.

  • 0 in reply to Einar Thorsrud

    I prefer to prevent non-NRF_SUCCESS return codes whenever possible. The fds_stat() strategy sounds like it will work.

Related