Root filesystem completely in RAM (only data mounts)

Unfortunately, I have to confirm that sdcards and flash storage fail (wasn’t the first time), so I looked if the root filesystem could be run completely from RAM in a satisfying a way.

“toram” seems to be a valid boot parameter but only valid for install media and does not support any persistence.

A while ago I came across the slax live distro which allows debian packages to nicely run in ram. It’s using a completely rewritten system to boot, install, and configure (now debian) packages into ram, and persist everything back into .sb “slax bundle” files ( savechanges [/alternative/place/for/]), which can then get loaded directly into ram on the next boot, reestablishing the saved state.
It struck me as the most advanced versatile ram system I had seen, so would like to ask what others think about running from ram for speed and wearless system operation.

A how-to-use walk through and technical info is available here:

1 Like

Making a read-only filesystem writable with a overlay mount should be straight forward enough. However, Flushing to changes disk seems like an explicit step in this system. This may not suite FreedomBox well where database will be updated with the expectations that changes will be synced to the disk immediately.

Which database do you mean? plinth? It could maybe trigger to save the changes after a package install or (re)configuration.

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 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.