Closed Ciantic closed 4 years ago
Reasons I did not use AUFS:
SD cards can also fail from read fatigue or power loss. The safest solution is to avoid accessing the SD card as much as possible.
Having a filesystem partition makes deployment harder. A ramdisk file can be copied with regular tools, checksummed etc. A filesystem partition is much easier to accidentally modify and requires relatively special tools to copy.
I simply don't need a full operating system for anything of the things I use this for, and a full system creates a lot more temporary and logs files that I would need to redirect or otherwise deal with.
That said it is a perfectly reasonable solution if you need it. It is what OpenWRT does for example. I don't know if they use AUFS or something else, but the end result is the same (and they also support writeback.)
Okay, thanks for you answers!
I'm working on a browser (chromium) kiosk with raspberry-pi, judging from your answer I think if I can I should try to use full rpi-ramdisk then. Only worry I have is that can I fit Chromium etc. in the ramdisk of RPI 4Gb memory.
Great effort! Following is not an issue in your work, but question for you since you have gathered lot of experience in this area.
Have you investigated using aufs? One reason to use rpi-ramdisk is to save SD card from corruption. But to my knowledge it can also be prevented by just setting the SD card read only.
Thus my question is have you investigated combining both parts: making SD-card file-system read only, and make all writes to go to ramdisk? This way it could support bigger distros, because the actual file system is retained in the SD-card.
I found this: https://unix.stackexchange.com/questions/27449/mount-a-filesystem-read-only-and-redirect-writes-to-ram which suggests that LiveCD distribution is doing something like that.