A HDD or SSD might not be available in all cases. The (arm) flash images could be read-only “live-images”, though, or using ramlog, and a separate data drive.
And with enough ram, of course copy the root filesystem into ram.
@sunil I’m still not sure what you were referring to above. But if you just meant all configuration and general user-data (web-app databases), then I’d picture all this to be mounted directly (reside on a writable data partition).
If it’s on SSD the logs can also reside on it, but otherwise it would be better to only save the logs to disk on log-rotation and shutdowns, to avoid disk spin-ups.
In the case of a crash, the user-data would be protected by the combined database and filesystem’s consistence guarantees.
While (ram) root filesystem changes are lost and get reset on the next boot.
I don’t know the exact reasons why ram systems don’t write changes to disk continuously, but only do it on some kind of savechanges requests. I guess it has to do with loosing the speed improvements and being able to guarantee a consistent state after crashes.
Your idea of just using an overlay fs with flushing support seems interesting, Unfortunately, I don’t know the reason why slax uses bundle files to save changes, either. Maybe to support adding and removing them for booting individually (e.g. for corresponding .deb packages or config changes). And to be able to add them up in a file that fits onto a FAT fs.
Revisiting, I’ve found slax also supports writing the changed files directly to a filesysem in a /slax/changes/ directory. And, that there exists https://www.linux-live.org/ which uses aufs3, and is from the same author as slax. So, he seems aware of overlay solutions and there are likely good reasons for the slax implementation.