New Feature: /tmp and /var RAM disks on Full installs; /tmp and /var resizing
-
https://github.com/pfsense/pfsense/commit/e92e83d4e2e3465bca9ca6d3cc4f746ef6566476
Add the ability for full installs to optionally use RAM disks for /tmp and /var, and to allow selecting a size for /tmp and /var RAM disks on both Full installs and NanoBSD.
I think I caught most of the edge cases for transitioning into and out of RAM disk mode, and preserving data across reboots as is done on NanoBSD (RRD, DHCP leases, pkg/pbi info).
Give it a spin, seems to work OK on my ALIX and full install VM I tested with.
Hopefully this will help alleviate a few issues:
1. Full installs on SSDs where people don't want to constantly write RRD and log data to the SSD
2. NanoBSD installs on systems with large amounts of RAM that want to use more advanced features that require more room in /tmp and/or /var
3. … -
Do I need to make a new installation to gain this feature?
-
No, it can be activated at any time once you're on a snapshot that has the code. There hasn't been a new snapshot since I added it last night, there is one building now.
To activate it, just go to System > Advanced, Misc tab, at the bottom, and check the box to turn it on.
If you are on the latest snapshot you can also gitsync and obtain the code as well, it did not require any binary changes.
-
New snapshots are up and it should be working OK for full installs.
I just found and fixed a bug that prevented the sizing from working on NanoBSD, so that will be OK on the next snapshot.
https://github.com/pfsense/pfsense/commit/efc0e29abc068b41f52a2d5d6ac89cb6c4791662 -
Would it make sense to use to use this feature on a Alix box with 256MB of ram?
-
Nice! Does the content of the ramdisk gets committed to the hard disk during a regular reboot/update?
Thanks,
Michele -
Would it make sense to use to use this feature on a Alix box with 256MB of ram?
Only if you need to slightly tweak the /tmp and /var slice sizes. There isn't much wiggle room on ALIX for that.
Nice! Does the content of the ramdisk gets committed to the hard disk during a regular reboot/update?
It works identically to NanoBSD. The RRD data and DHCP lease data are backed up on shutdown/reboot and restored at bootup. The options for periodic backup of those items also works on here. Also like NanoBSD, the pbi/pkg info is held in /root rather than /var/db/pkg
-
On Alix, on the console during boot, I get:
Mounting filesystems... [: -gt: unexpected operator [: -gt: unexpected operator Setting up memory disks... done.[/code] I think that spits out of rc.embedded when use_mfs_tmp_size and use_mfs_var_size have not been set in the config. It still falls through the tests somehow and ends up with the default 40MB and 60MB memory disks. -
On Alix, on the console during boot, I get:
Mounting filesystems... [: -gt: unexpected operator [: -gt: unexpected operator Setting up memory disks... done.[/code] I think that spits out of rc.embedded when use_mfs_tmp_size and use_mfs_var_size have not been set in the config. It still falls through the tests somehow and ends up with the default 40MB and 60MB memory disks. I think that's the bug I fixed with the commit I linked, make sure you've got that one (or try another snap after) The problem was the config slice wasn't mounted when it tried to read the config, so the file wasn't there. The command should always get a number back from grep -c so long as the file exists, but I could add some extra protections just in case. -
It needs a bit fancier checking for null values in rc.embedded - I just submitted a pull request. You might have a neater way of making it do the "-gt 0" check against a possibly empty variable.
-
Nah your check is fine, I merged it. Thanks!
-
Great feature, thanks! Works fine so far.
-
Installed the latest snapshot, turned on this feature. Left blank for default space. Installed Squid3 and after reboot it gives me the below error on the login page and I am locked out as I cannot log into the system. The pfSense is a remote box and I don't have physical access to it. Darn !
Warning: session_start(): open(/var/tmp//sess_a5f98c219d39beb8a18480d9a81a2024, O_RDWR) failed: No space left on device (28) in /etc/inc/auth.inc on line 1316
-
Well what did you expect when you gave it a pittance for space in /tmp and /var and tried to install a package that used it all up?
Unfortunately there is no way to prevent foot-shooting there, but I suppose I could add even more stern warnings to the page.
-
I realized about the setting just the second after I clicked reboot. Any backdoor method to gain access to the system?
-
Hard to say for sure, if you can get it to the console menu at all you might be able to go back to an older version of the config, assuming any are there. It very well could have wiped out quite a bit if /tmp and/or /var filled up.
If you can get to a prompt, check /conf/backup/ and see if there are any old configs there, if there are, then copy one to /conf/config.xml, rm /tmp/config.cache, and reboot
-
Can't do much remotely. Only access I had to it was over WAN https.
-
Updated to the latest snapshot via automatic update. No option in System-Advanced-Mics.
What am I doing wrong? -
is it possible to create a option for a third RamDisk?
So we can choose Squid/HAVP/etc for using this space for caching!
so the normal usage of /tmp and /var is not affected?! -
@w0w:
Updated to the latest snapshot via automatic update. No option in System-Advanced-Mics.
What am I doing wrong?Which option is not there?
On nanobsd, the checkbox "Use memory file system for /tmp and /var" does not appear, because it is not optional - it always "Uses memory file system for /tmp and /var".
