geky
commented
9 months ago Hi @cmorganBE, thanks for creating an issue.
This is an interesting idea. One could imagine an optional define that makes these counters available through lfs_fs_stat.
Though I wonder if inside the filesystem is the best place for these. You could also add the counters to the block device itself, and query the block device outside the filesystem. That way you could also measure any overhead introduced by other block device layers (FTL, ECC, etc).
This is what we do in emubd for running local (no-hardware) benchmarks: https://github.com/littlefs-project/littlefs/blob/f53a0cc961a8acac85f868b431d2f3e58e447ba3/bd/lfs_emubd.h#L199-L206
Reviewing lfs.h and the port for esp32 I'm using here I don't see any tracking counters exposed from littlefs.
It would be helpful for embedded use to be able to retrieve counters of page writes and page erases from littlefs to aid in the analysis of product lifespan.
The simple analysis is to look at the datarate from the application into littlefs, however this excludes overhead and other internal management of the filesystem that may add overhead. Having run-time counters (stored in ram, not persisted to the filesystem), for erases, block writes, and block reads, a block read count could let you examine if your application's workload was somehow causing more reads than anticipated, would provide the information necessary for an analysis.
Thoughts?