Mount /tmp as an MFS?
-
Hi, if this idea has been brought up before, then I'm sorry and please forgive me. I am new to pfSense, though not to FreeBSD, and I would like to help out, though perl is not my strong point. As I am phasing out my old firewall (this is my old firewall: FreeBSD fw.example.com 4.8-STABLE FreeBSD 4.8-STABLE #0: Sat May 17 20:47:56 PDT 2003). I am comparing it to pfSense to see what direction others have gone.
One big difference is that I mounted /var as an mfs, and /tmp is a symbolic link to /var/tmp. At boot time, /usr/sbin/mtree uses /etc/mtree/var.dist to reconstruct /var in the newly mounted mfs. Currently in pfSense 2.0.1 only /var/run is an mfs. What are your thoughts on making /tmp an mfs? Or even all of /var? My interest is that I transfer a web cam image from a device in the interior of my network to the firewall for access by the outside, every 10 seconds. Also RRD tends to generate it's temporary PNG graph files in /tmp.
Thanks,
Andrew
-
Perhaps I am unaware of its common use but MFS seems to have several possible meanings. I assume you mean Memory File System?
In which case I am confused since both /tmp and /var are already mounted as a ram drive:
[2.0.1-RELEASE][root@pfsense.fire.box]/root(7): mount -p /dev/ufs/pfsense0 / ufs ro,sync,noatime 1 1 devfs /dev devfs rw 0 0 /dev/md0 /tmp ufs rw 2 2 /dev/md1 /var ufs rw 2 2 /dev/ufs/cf /cf ufs ro,sync,noatime 1 1 devfs /var/dhcpd/dev devfs rw 0 0Edit: Though this is with the NanoBSD install type.
Steve
-
Yes, sorry, MFS is "memory file system". In my plain vanilla pfSense installation this is what my mount points look like:
/dev/ad4s1a / ufs rw 1 1 devfs /dev devfs rw 0 0 /dev/md0 /var/run ufs rw 2 2 devfs /var/dhcpd/dev devfs rw 0 0The fstab is only used to mount the root files system and swap (if you have a second partition):
# Device Mountpoint FStype Options Dump Pass# /dev/ad4s1a / ufs rw 1 1 /dev/ad4s1b none swap sw 0 0Normally, in a FreeBSD installation, there is an /etc/rc.conf that controls much of the installation that varies from /etc/defaults/rc.conf. Several useful options available from the FreeBSD rc initialization system are:
tmpmfs="AUTO" # Set to YES to always create an mfs /tmp, NO to never tmpsize="20m" # Size of mfs /tmp if created tmpmfs_flags="-S" # Extra mdmfs options for the mfs /tmp varmfs="AUTO" # Set to YES to always create an mfs /var, NO to never varsize="32m" # Size of mfs /var if created varmfs_flags="-S" # Extra mount options for the mfs /var populate_var="AUTO" # Set to YES to always (re)populate /var, NO to never cleanvar_enable="YES" # Clean the /var directoryDoes your fstab create and mount the /var and /tmp devices? Or is it handled in /etc/rc.conf? Or is this part of the pfSense initialization for your NanoBSD install? I'm not familiar with the difference. Here's my system:
FreeBSD firewall.example.com 8.1-RELEASE-p6 FreeBSD 8.1-RELEASE-p6 #0: Mon Dec 12 17:33:39 EST 2011 root@FreeBSD_86which came from Jim P. here: http://files.pfsense.org/jimp/pfSense-memstick-serial-2.0.1-RELEASE-i386.img.gz
Thanks-
Andrew
-
The NanoBSD images are for installing to flash based boot media such as a CF card in an IDE adapter.
Since there are limited writes for flash storage the tmp and var folders are run from ram and others are mounted read only.
If this is what you are looking for it might be easiest to use a Nano image./etc/rc.conf is overwritten by the scripts that make up pfSense at boot time.
This is now out of my league I'm afraid. If you're looking for advise on significant modification to the install then probably best to wait for one of the developers. ;)
Steve
-
Yes, I noticed that your config.xml is in a separate /cf mount point for a separate device. My installation is constrained because I am serial console only, and Jim P's install image was the only working one at the time. I am also diskless on a net6501 - the root file system is an mSATA flash drive. That's part of my motivation to move to a memory file system for /tmp and /var.
It sounds like you are doing fine with an mfs /var, which means that nothing important is placed in it that must be kept between boots. My old system put /tmp into /var/tmp so that only one memory file system was created. I believe that modern FreeBSD, using TRIM, can pare the memory used by the file system to the minimum necessary, as it grows and shrinks. I'll experiment with this later.
Thanks-
Andrew
-
Ooops, it looks like TRIM support is FreeBSD 9, not 8.1 as pfSense 2.0.1 is based on. At least mdmfs did not recognize the -t flag.
Andrew
-
I found why /etc/rc.conf is deprecated:
# Make sure /etc/rc.conf doesn't exist. if [ -f /etc/rc.conf ]; then /bin/rm -rf /etc/rc.conf fiThe problem is that this /etc/rc goes too far too quickly, so it must create and mount the memory file systems itself, instead of relying on /etc/rc.d/tmp and /etc/rc.d/var. The "nanobsd" and "embedded" platforms /etc/platform get abridged /tmp and /var MFS initializations from /etc/rc.embedded, while the "cdrom" platform uses /etc/rc.cdrom which in turn calls /etc/rc.d/tmp, /etc/rc.d/varmfs and /etc/rc.d/etcmfs. However, the "pfsense" platform only initializes a hard-coded 4MB /var/run MFS.
For version 2.1 I would like to suggest that the platform prologue code in /etc/rc be changed to a case statement, and "pfsense" platform specific code be moved to /etc/rc.pfsense. Also, memory file system initialization should be relegated back to the specific /etc/rc.d files. This will help ease synchronization with new FreeBSD releases, as well as make life a little bit easier for customizers like me. Even further, returning to the FreeBSD /etc/rc.conf system of customization parameters will go a long way towards making life much simpler for everyone.
What do you think?
Andrew
-
This depends a lot from point of view.
Though if patches come up for sure they will be looked after!
-
I have set in /etc/defaults/rc.conf :
tmpmfs="YES" # Set to YES to always create an mfs /tmp, NO to never
tmpsize="60m" # Size of mfs /tmp if created
tmpmfs_flags="-S" # Extra mdmfs options for the mfs /tmp
varmfs="YES" # Set to YES to always create an mfs /var, NO to never
varsize="32m" # Size of mfs /var if createdIn a full install, but neither /tmp/ nor /var are created in mdN device.
Do I need to add some lines to /etc/rc to make this go????
Should I put something in /etc/fstab instead?–------------------------------------------------------------------------------
FYI: Sun Oct 21 09:53:19 CDT 2012I created an /etc/rc.conf.local and added entries for
/etc/rc.d/tmp
/etc/rc.d/varBut that created an infinite loop, creating many /tmp and /var, and stalled the boot loader. I was able to drop into administration mode and delete
/etc/rc.conf.local and reboot.My later attempt to minimize writes to the SSD was to manually set in /etc/platform to "embedded".
Doing so creates the correct md0 and md1 for /tmp and /var, but it also kills the "packages" button in the GUI.
I created a utility rc.lockdown that simply toggles /etc/platform between "pfSense" and "embedded" so that I can
manage packages (which isnt a problem, since you only install packages occasionally).I'm sure that what I am doing is not standard or persistent accross upgrades, so please let me know if you see a better way.
-
If you set /etc/platform to "nanobsd" then it should do the memory file system md0/md1 stuff, and the packages list will show you the packages that are suitable for the nanobsd platform. It might all work, but doing a full install and then changing it to "nanobsd" under-the-hood might have other effects, good and bad - e.g. Diagnostics:NanoBSD will probably show up on menus, giving options to duplicate boot slices… The option to periodically backup RRD and/or DHCP lease data might be handy though, if it works in such a config.
With SSDs these days, there is a use-case for having a hybrid install that can put a full install on a chunk of an SSD, then also select the nanobsd-style features that are desired - putting tmp and var in memory, periodically backing up useful stuff from tmp and var to the SSD, preserving various things during a clean shutdown...
