Indeed the RAW address is UGLY - but prevents WASTE of that 32KB - though it DOES assure that any leftover DMAMEM is blocked form dynamic allocations.
You could use malloc() and allocate enough memory that the address exceeds the 32kb. - and then free the unused memory. This is also not pretty, but cleaner, and nothing would be wasted.
With this talk of what is "clean" versus "ugly", maybe it's time (before 1.55 release) to reconsider whether RAM filesystem persistence is useful or even a reasonably good idea at all.
My concern is something that's fun from an academic perspective may actually be a fundamentally bad design. The main problem is LittleFS doesn't make any strong checks on data integrity, like CRC checks or a duplicate allocation table (as FAT does). While this conversation has a laser-like focus on behavior across code updates, that probably isn't the most important consideration. In nearly all practical applications, code updates are infrequent. What does happen often during realist usage is power cycling. Software bugs where a fault or watchdog reboot recovers are also an important consideration.
The possible problem is RAM tends to retain data for a short time after power loss. But not reliably. Each bit has higher chance of initializing in a different state the longer power is lost. With even a short power loss, odds of all bits correct are low, but odds of some or even many bits retaining their original state are pretty surprisingly high.
If we reboot due to some form of automatic recovery from an unknown software bug, trusting the prior contents of RAM also seems like a rather risky idea.
LittleFS initialization looks for a relatively small amount of metadata to recognize a filesystem. The entire design of LittleFS is built on top of the assumption of reliable non-volatile memory. LittleFS does very little to check whether the storage media is faulty.
Perhaps we should completely remove RAM persistence support?
If it remains, at the very least I want to see the begin() function do better checking. If the prior reboot was due to power on reset, the RAM definitely needs to be wiped clean. Maybe we should also wipe if the reboot was cause by any sort of fault?
But a better question is why do we even have such a risky feature?!