On Thu, Nov 08, 2018 at 11:45:47AM -0800, Christopher Collins wrote: > I. What gets persisted - individual stats, or entire stat modules? > 1. Individual stats: we waste flash by including the module name in > every record. > > 2. Entire stat modules - two options: > a. Waste flash persisting unchanged stats, or > > b. Need to to remember which stats have changed since the last > time the module was persisted. This allows us to only > persist stats whose values have changed. > > I think option 2b is the best. There is some implementation effort, but > the savings in flash usage is worth it, in my opinion.
(I forgot to mention: I am assuming these persisted records would be stored using the sys/config package.) After giving this some more thought, I am not sure 2b is such a great option. The problem is: how do we ensure we don't lose any stats due to FCB rotation? During rotation, the sys/config package preserves the latest value for each key; overwritten values get garbage collected. This ensures the sys/config user doesn't lose any information, but it only works if each config key corresponds to a consistent set of data. In the implementation I described, the set of data getting persisted is not consistent. Each entry would only contain the set of stats that changed since the last write. I can't think of a good way to ensure sys/config doesn't drop some stats during garbage collection. Now I am thinking it is probably best to just persist the entire stat module every time. It would be up to the developer to reduce flash wear with a combination of: 1) smaller stats modules, 2) larger persistence delays,a and 3) only persist stats that don't change often. Chris
