[CLUG-tech] Best practice for compact flash mounted root

marc marc at jade.cs.uct.ac.za
Tue Feb 21 15:29:22 SAST 2006

> Obviously with compact flash you don't want to write to the root filesystem 
> all the time so I'm wondering what to do to prevent that. Googling supplies a 
> surprisingly limited set of answers. 

Make / readonly.

> The questions I'm considering are:
> Can I put /var on a ramdisk and unpack a tar archive to it at boot time?

Yes. I suggest tmpfs (mount -t tmpfs tmpfs /var), instead of a /dev/ram? disk

> How much RAM to waste?

tmpfs allocates on demand, up to a hard limit. Depends on your
requirements, but the default of half of RAM is usually ok

> How about doing the same thing with unionfs?
> The odd write to /etc/mtab at reboots shouldn't be a problem as it doesn't 
> happen that often.

As Izak said, link to /proc/mounts. mount will not attempt to update
mtab if it is a symlink (slightly broken logic though, I have submitted
a patch to update if it is a link to say /var/run/mtab, though it is 
unclear if that will get accepted, since mount is suid).

> Obviously there shouldn't be a swap partition and the noatime flag should be 
> set on the flash mounted filesystems.

Also make it non-journaled, so that in the case you do need
to modify it you halve the number of writes to it. Use mount -o remount,rw /
and ro to toggle that.

> Is there any point in using tmpfs without swap?


> Does /tmp on a ramdisk make 
> sense? 

Yes, but I suggest a symlink from /tmp to /var/tmp

> How do I make ramdisks of differing sizes?

Use tmpfs and specify a size option

> Is it worth trying to mount / read only?

Yes. Most plain systems will run with only /tmp and /var writable.
For a while debian /etc/network/ifstate was a problem (gah, what were
they smoking), but thesedays it can be worked around with a symlink.
Or just bypass it by configuring the network interfaces with 
a custom setup script.

However, one does fear that the trend toward more
autodetection and autoconfiguration (and generally running steaming piles
of perl and python scripts behind the owners back, some with delusions
of being system daemons) is going to make it somewhat harder to trim 
a distribution to a small readonly system. 



More information about the Clug-tech mailing list