Re: /var on tmpfs
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?
Re: /var on tmpfs
On Thu, Nov 15, 2018 at 10:28:56PM -0700, Don NetBSD wrote:
> I've a box with a DoM. I'd like to mount / as ro and create a
> tmpfs for /var (and /tmp). I don't think anything else NEEDS to
> be rw (the infrequent changes to /etc can be made by unlocking /
> to make those changes).
>
> I imagine I can just make a tarball of a skeletal /var and
> unpack this over /var, once mounted?
>
> Is there a preexisting mechanism for this sort of thing?
> Or, do I roll my own?
I have done this before.
I added an rc script for copying filesystems on non-volatile (NV)
storage to memory filesystems and then null-mount the memory
filesystems on top of the NV directories. See attachment.
I added a line to /etc/fstab,
swap /mfs tmpfs rw,-s8M 0 0
I modified my rc.conf to 1) indicate that /etc, /var, temporary and
home directories should be on (ephemeral!) memory filesystems, and 2)
ensure that the prerequisite filesystems (/usr) were mounted before
mountcritmem ran.
# When /usr is on a different filesystem than /, I mount it
# before the memory filesystems so that pax can run programs
# from it.
#
critical_filesystems_beforemem="/usr"
# Do not mount /var, it's a memory fs. Superfluous, since NetBSD
# will not mount /var a second time, anyway.
#
# critical_filesystems_local=""
# Don't mount /usr, it comes with / on the CD-ROM.
#
critical_filesystems_remote=""
# Don't mount /usr, it comes with / on the CD-ROM.
#
critical_filesystems_memory="/etc /home /root /tmp /var"
If this works for you, too, maybe mountcritmem should go into the base
system.
Dave
--
David Young
dyo...@pobox.comUrbana, IL(217) 721-9981
#!/bin/sh
#
# $NetBSD$
# $Id: mountcritmem 4133 2006-08-26 06:10:29Z dyoung $
#
# PROVIDE: mountcritmem
# REQUIRE: root
# BEFORE: mountcritlocal
$_rc_subr_loaded . /etc/rc.subr
name="mountcritmem"
required_dirs="/mfs /permanent $critical_filesystems_memory"
for _d in $critical_filesystems_memory; do
d=${_d#/}
required_dirs="$required_dirs /permanent/$d"
done
start_cmd="mountcritmem_start"
stop_cmd="mountcritmem_stop"
#
# Example /etc/fstab
#
# /dev/wd0a / ffs ro 0 0
# swap /mfs mfs rw,-s=10880k,-i=256 0 0
abort_mountcritmem()
{
if [ "$autoboot" = yes ]; then
echo "ERROR: ABORTING BOOT (sending SIGTERM to parent)!"
kill -TERM $$
exit 1
fi
}
mountcritmem_start()
{
if [ "${critical_filesystems_memory:-}" = "" ]; then
return 0
fi
echo "Mounting critical memory filesystems"
_fs_list=
for _d in $critical_filesystems_memory; do
d=${_d#/}
_fs_list="$_fs_list $d"
done
for d in $_fs_list; do
if [ ! -d /permanent/$d ]; then
echo "ERROR: missing /permanent/$d"
abort_mountcritmem
return 1
fi
done
for d in $_fs_list; do
if ! mount /mfs; then
echo "ERROR: cannot mount /mfs"
abort_mountcritmem
return 1
fi
break
done
for d in $_fs_list; do
if ! mkdir /mfs/$d; then
echo "ERROR: cannot mkdir /mfs/$d"
abort_mountcritmem
return 1
fi
done
for d in $_fs_list; do
if ! mount -t null /$d /permanent/$d; then
echo "ERROR: cannot mount /permanent/$d"
abort_mountcritmem
return 1
fi
done
for d in $_fs_list; do
cd /permanent/$d
if ! mount -t null /mfs/$d /$d; then
echo "ERROR: cannot mount /mfs/$d"
abort_mountcritmem
return 1
fi
if ! pax -pe -rw . /$d ; then
echo "ERROR: cannot populate /mfs/$d"
abort_mountcritmem
return 1
fi
cd -
done
}
mountcritmem_stop()
{
if [ "${critical_filesystems_memory:-}" = "" ]; then
return 0
fi
_rev_fs_list=
for _d in $critical_filesystems_memory; do
d=${_d#/}
_rev_fs_list="$d $_rev_fs_list"
done
for d in $_rev_fs_list; do
umount /mfs/$d
umount /permanent/$d
done
for d in $_rev_fs_list; do
umount /mfs
break
done
}
load_rc_config $name
run_rc_command "$1"
Re: /var on tmpfs
Don NetBSD wrote: I've a box with a DoM. I'd like to mount / as ro and create a tmpfs for /var (and /tmp). I don't think anything else NEEDS to be rw (the infrequent changes to /etc can be made by unlocking / to make those changes). I imagine I can just make a tarball of a skeletal /var and unpack this over /var, once mounted? Is there a preexisting mechanism for this sort of thing? Or, do I roll my own? How about using union mounts? I don't think you can do that for /, but for /var it should let you have your cake and eat it too. Just a thought. Staffan
Re: /var on tmpfs
On 11/16/2018 12:35 PM, Rhialto wrote: I once made a little script to make a bootable ISO9660 live file system, given the distribution tarballs. It has to be able to live on a read-only medium, hence it uses a tmpfs for /var. For initializing it, it installs a script in /etc/rc.d. I basically used trial and error; everything that produced an error message while booting was reason for adding an extra directory or empty file. https://www.falu.nl/~rhialto/mkiso I just gave it a quick try, and qemu seemed a looot slower than previously (when I last tried was under 7.0.2 I think)... Thanks, I'll have a look.
Re: /var on tmpfs
On 11/16/2018 11:12 AM, Jeremy C. Reed wrote: On Thu, 15 Nov 2018, Don NetBSD wrote: I've a box with a DoM. I'd like to mount / as ro and create a tmpfs for /var (and /tmp). I don't think anything else NEEDS to be rw (the infrequent changes to /etc can be made by unlocking / to make those changes). I imagine I can just make a tarball of a skeletal /var and unpack this over /var, once mounted? Is there a preexisting mechanism for this sort of thing? Or, do I roll my own? Have a look at the /etc/mtree/ specifications. Many /var/ entries in there. You could use it to create your own spec file for your required files and directories with correct ownership and permissions and then run mtree to generate them. Ah, that would be a clever approach -- and, add little/nothing to the image size as the entries would already exist in the existing specs (I'd just be "moving" them into another spec). But, it won't let me create *files*. So, if I wanted to symlink all or part of /etc to, for example, /var/etc (to eliminate the need for creating a second tmpfs -- and incurring a second "overhead"), I'd still need a mechanism to instantiate those files under /var. Or (looking at my notes from 2002), I used a /var.copy directory pre-populated as needed and after the /var was mounted and "cp -R -p /var.copy/* /var" into it. I'd thought: # mount_tmpfs tmpfs /var -- populate /var, as needed # mount -u / # tar czpf /somewhere/var.tgz /var Then, just unpack the tarball onto the newly mounted /var in rc(5). But, regardless, the point is that there is no preexisting mechanism in place for this sort of thing? E.g., FBSD had an rc.diskless (a bit of overkill) that could be modified to achieve these sorts of results.
Re: /var on tmpfs
I once made a little script to make a bootable ISO9660 live file system, given the distribution tarballs. It has to be able to live on a read-only medium, hence it uses a tmpfs for /var. For initializing it, it installs a script in /etc/rc.d. I basically used trial and error; everything that produced an error message while booting was reason for adding an extra directory or empty file. https://www.falu.nl/~rhialto/mkiso I just gave it a quick try, and qemu seemed a looot slower than previously (when I last tried was under 7.0.2 I think)... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: /var on tmpfs
On Thu, 15 Nov 2018, Don NetBSD wrote: > I've a box with a DoM. I'd like to mount / as ro and create a > tmpfs for /var (and /tmp). I don't think anything else NEEDS to > be rw (the infrequent changes to /etc can be made by unlocking / > to make those changes). > > I imagine I can just make a tarball of a skeletal /var and > unpack this over /var, once mounted? > > Is there a preexisting mechanism for this sort of thing? > Or, do I roll my own? Have a look at the /etc/mtree/ specifications. Many /var/ entries in there. You could use it to create your own spec file for your required files and directories with correct ownership and permissions and then run mtree to generate them. Or (looking at my notes from 2002), I used a /var.copy directory pre-populated as needed and after the /var was mounted and "cp -R -p /var.copy/* /var" into it.
