Peer Manager deletes only peer while we still need it -- failed flash write race?

RE: Peer Manager deletes only peer while we still need it -- failed flash write race?

Einar Thorsrud — Tue, 02 Nov 2021 08:09:25 GMT

Yes, this is resolved in 17.1.0. You can see the diff here:

devzone.nordicsemi.com/.../cache_5F00_fix.diff

RE: Peer Manager deletes only peer while we still need it -- failed flash write race?

Jackson Burnette — Mon, 01 Nov 2021 17:06:37 GMT

[quote user="eith"]

Jackson Burnette said:
It seems like there is a lot of GATT DB cache updates that result in flash changes.

Yes, you are right. The peer manager will write to flash every time a bonded peer connects, as discussed in this thread. This issue will be resolved in the next nRF5 SDK release which is right around the corner.

[/quote]

Hi Einar 👋 Has the issue been resolved in SDK 17.1.0? If so, is there a diff you can provide of the specific change?

RE: Peer Manager deletes only peer while we still need it -- failed flash write race?

Einar Thorsrud — Tue, 24 Aug 2021 15:21:39 GMT

I am glad to hear that. It is good if you close cases when they are resolved. You do not loos access to them, and can also re-open if needed.

RE: Peer Manager deletes only peer while we still need it -- failed flash write race?

Jackson Burnette — Tue, 24 Aug 2021 13:55:02 GMT

Great, thanks very much Einar. Really appreciate your prompt and informative responses.

One last question. I'm relatively new to devzone, if I feel you've answered my question should I click the "Close this Case" button? If I do, will I lose access to the contents of this post?

RE: Peer Manager deletes only peer while we still need it -- failed flash write race?

Einar Thorsrud — Tue, 24 Aug 2021 06:19:00 GMT

Hi,

[quote user="Jackson Burnette"]It seems like there is a lot of GATT DB cache updates that result in flash changes.[/quote]

[quote user="Jackson Burnette"]Does the peer manager take care of deleting the stale GATT DB caches so that they are cleaned up on GC?[/quote]

Yes, old caches are deleted, so GC will free that space.

RE: Peer Manager deletes only peer while we still need it -- failed flash write race?

Jackson Burnette — Mon, 23 Aug 2021 16:19:13 GMT

Thanks for the reply!

[quote user="eith"]That is the case if you have deleted or updated some records without doing garbage collection before. If so, garbage collection will free the old dirty records, so that you get available space. If not, and you actually have too much data stored (typically also from other FDS data, not related to the peer manger), it will not be enough.[/quote]

It seems like there is a lot of GATT DB cache updates that result in flash changes. I think those updates are a big reason why we're running out of space so frequently. Does the peer manager take care of deleting the stale GATT DB caches so that they are cleaned up on GC?

RE: Peer Manager deletes only peer while we still need it -- failed flash write race?

Einar Thorsrud — Mon, 23 Aug 2021 16:11:01 GMT

Hi,

[quote user=""]If I understand the code and sequence of events correctly, garbage collection without peer deletion would actually be sufficient.[/quote]

That is the case if you have deleted or updated some records without doing garbage collection before. If so, garbage collection will free the old dirty records, so that you get available space. If not, and you actually have too much data stored (typically also from other FDS data, not related to the peer manger), it will not be enough.

There are a few things to note here, some of which are related to a few things not handled very well in the peer manager. First of all, you cannot delete the bond for a peer that is currently being used. That will lead to undefined behavior in the peer manager. However, the peer manager does not prevent deleting the bond for a peer that is currently connected. Secondly, as you note, the peer manger PM_EVT_STORAGE_FULL will trigger deletion of the oldest peer even if it is the only peer.

[quote user=""]

My current plan is to disable peer ranking in our SDK configuration so that the peer manager will never auto delete any peers. We have internal handling that will mark peers for deletion when they are no longer needed.

Any suggestions or corrections based on the summary above?

[/quote]

That makes sense. Either that, or improve the peer manager handling of this scenario. Altos, another approach sometimes used is to regularly check the amount of free space in FDS, and do a garbage collection if there is a need for that (there is memory to be freed, and amount of free space is limited). Potentially also delete old and no longer needed data before doing the GC.

Einar