Re: /var on tmpfs

[Don NetBSD <netbsd-embedded%gmx.com@localhost>]

On 11/16/2018 3:47 PM, David Young wrote:
> I added a line to /etc/fstab,
>
> 	swap /mfs tmpfs rw,-s8M 0 0

If memory is limited, doesn't that make creating a MFS swap just useless
overhead?  I.e., if you need to page to swap, you're just consuming memory
set aside FOR swap instead of "main memory"/buffer pool?

> I modified my rc.conf to 1) indicate that /etc, /var, temporary and
> home directories should be on (ephemeral!) memory filesystems, and 2)

Doesn't mfs have a higher overhead than tmpfs?

> ensure that the prerequisite filesystems (/usr) were mounted before
> mountcritmem ran.

> If this works for you, too, maybe mountcritmem should go into the base
> system.

With memory also being in short supply, I think the approach I should
take is to create a "volatile" partition backed with tmpfs mounted at,
for example, /volatile.

Then, *selectively* add symlinks from the ro portion of the filesystem
into that.  E.g., /tmp can point at /volatile/tmp to ensure ALL of
/tmp is backed with a volatile store.

This allows a finer-grained use of that (precious) resource -- memory.
E.g., printcap(5) can remain in the ro backed /etc... but, /etc/myname
can move to the volatile store.

[Aren't there some parts of /etc that various daemons update and, thus,
need to be writable?]

Finally, after instantiating everything that needs to reside in /volatile
(proper filenames, contents, ACLs, etc.) -- along with any required symlinks
from the ro portion of the filesystem -- build a tarball and stash it on
the persistent portion of the filesystem.

Then, reboot just needs to create /volatile and mount it; then populate it
with the contents of that tarball.

One caveat:  I'd have to create a /volatile hierarchy on the persistent
medium and mount the tmpfs on top of it.  This ensures that the parts
of the filesystem that will eventually be volatile are present even before
the system moves to multiuser!

Have I missed anything?

Finally, besides /var and /tmp, which *files* must be mutable -- acknowledging
that this may depend on the actual set of services in use, at the time (DHCP
client, BIND, etc.)?  Does /dev need to be mutable -- aren't owners and
perms changed dynamically for some devices by the system/services?