FDS_EVT_GC results in NRF_SUCCESS but with remaining freeable words

Question

Hello, 
 We have nRF52832 in production on a custom board. Recently, we created a new functionality with the aim to handle flash more efficiently, and to avoid the case where peer manager will not have enough space and it will erase bonds. So, every time before saving any kind of record, words_used + new record size is checked that is less than the determined limit and then saving in flash is allowed. We also call two times a day the fds_gc, as long as there is no BLE connection at the time. 
 The problem is that from many clients devices we receive logs that we have set in order to track gc behaviour. This kind of log is set after FDS_EVT_GC and if this event returns NRF_SUCCESS. In this case we call fds_stat to witness the result of garbage collector, but unfortunately, it returns the same number of freeable words at every gc call. We have this log from many users for days, and we do not know why this happens, and why it doesn't delete all freeable words but still returns nrf_success? When I say the same number I mean same number again and again for each user, e.g. one user has 1458, another 2012, etc. 
 Why does this happen? How can we solve this problem? 
 Thank you in advance. 
 Dimitra

DimitraN · Accepted Answer

Hello, 
 Jared said: Another plausible reason for the GC skipping pages is if the record is already open when the garbage collection is started. 
 Usually the number of freeable left is a lot larger than a record, but it is close to the size of a virtual page which is 2048 words. I found this at fds.h at function fds_record_close * Closing a record allows garbage collection to run on the virtual page in which the record is
* stored (if no other records remain open on that page). 
 
 I think I found what the problem was! After a reset (or a power-up) I call some function to retrieve data from flash to set some variables. There we didn't close one record so the GC would not run on its page. Probably this happens to clients that leave the device for a long time without charge and it eventually turns off. Also I had a call of GC right after updating another record, which probably make them run simultaneously or at least GC might run before finishing the update and maybe this causes the problem again. I have confirmed at least twice that this error has not occured after correcting the above . Thank you very much for your help! Regards, Dimitra