[FR] Flash wear leveling for STM32H7xx platform(implemented) + persistent storage efficiency question

[rondlh]

Is your feature request related to a problem? Please describe.

I have a STM32H723 motherboard that doesn't have an onboard i2c eeprom.
So I want to use FLASH_EEPROM_EMULATION, and of course FLASH_EEPROM_LEVELING, but this is not supported on the STM32H7xx platform.
I have implemented this and can share it if there is interest.

I have a question: Lots of unused settings are saved which makes the flash reading and writing slow and makes wear leveling less efficient.
For example, although I use AUTO_BED_LEVELING_BILINEAR, still a grid of 3 x 3 MESH_BED_LEVELING z-values etc. (total 44 bytes) are saved and read back.

Settings.cpp seems to explains this:

If a feature is disabled, some data must still be written that, when read,
either sets a Sane Default, or results in No Change to the existing value.

This idea is only used for some settings.
If we just don't save/load the MESH_BED_LEVELING values and leave them at their (safe) defaults then I see not issue. If we enabled MESH_BED_LEVELING then when loading the settings Marlin would see that the settings datasize is different and the saved settings are not accepted, and all values would stay at their (safe) defaults.

Even if I would change from AUTO_BED_LEVELING_BILINEAR to MESH_BED_LEVELING with a 3 x 3 grid, then still the saved data would not be accepted because likely the settings datasize changed. I don't use the default 3 x 3 grid for AUTO_BED_LEVELING_BILINEAR.
So what's the purpose of saving and loading lots of unused "dummy" data that will most likely never be used?
I think with a few low hanging fruit optimizations the settings size could easily be below 1K bytes.

BTW: I think it's possible to change some settings, but still the settings datasize stays the same, this might cause unsafe values to be loaded because the data is misaligned. I think this will be hard to prevent, unless a reset of the settings is forced at new builds.

Are you looking for hardware support?

No

Describe the feature you want

Flash wear leveling for STM32H7xx platform (I have implemented this already, ready to share)

Additional context

No response