Can I enable RAM disk just for /tmp but not /var on 2.2.3 HDD/SSD install?
-
I have been Googling around and have been unable to find a clear answer to this.
I want to enable a RAM disk for /tmp as I have my own script(s) running that generate json statistic files every couple of a seconds. This way I can have various router stats displayable on multiple machines simultaneously, without wasting CPU cycles on multiple calls of the rate command, etc.
I naturally would rather not commit this data to the KingFast SSD I am using as:
- I have no idea the reliability of this brand.
- It has a delay updating the json file that does not happen when using a RAM disk. This delay means sometimes the AJAX request fails, even though I create the file as a temporary file which is then renamed to the file accessible from the web server. (the theory being that is near-instant so unlikely to request the file when its incomplete)
I do not want to enable a RAM disk for /var as I already have 1.7GB of ntopng files in there. I probably don't need them, but with a 32GB SSD I don't see the point in skimping on the storage. Although I admit, its kinda conflicting with point one above. ;)
Currently I'm just writing the stats to a file in /var/run instead which is fine, but I'm guessing its probably not recommended?
-
The current code moves them both together based on a single boolean use_mfs_tmpvar that is set in /usr/local/www/system_advanced_misc.php
That code could be changed to have 2 checkboxes - use_mfs_tmp and use_mfs_var - with the necessary downstream changes wherever it is used and code to upgrade existing configs. I wonder if there are more use cases for that than just 1 install? -
I should certainly think so. Its standard procedure to have /tmp in a RAM disk on every other platform I have ever seen and it should speed up graph generation a fair bit.
Even if not, isn't it better to have the option anyway? Its not like it would be huge amounts of work to have two tick boxes rather than one. It baffles me why that wasn't the obvious choice when implementing this.
-
Always been wondering why's /var tied with /tmp as well…
-
Indeed, its bizarre as stuff in /tmp generally is small and (as the name suggests) temporary. Exactly the sort of stuff RAM is there for.
Stuff in /var however is not unusual to be quite large and is stuff you really want to preserve between reboots. So surely its actually a much smaller minority who want /var in RAM than want /tmp?
-
Think it was initially done for the nano builds to be easier on flash drives. Var, though maybe not completely "tmp" in nature is pretty dynamic so probably made sense for nano installs. Then later the option was included as-was into the full builds also. So think it just came about as a progression.
But I could just be making stuff up in my sleep.
I don't mind var being ram-disk too. I just created a vvar directory for anything I want to keep. Though I would like to see the firewall log saved and restored too along with the RRD graphs.
-
It is easy to do. This makes separate options for /tmp and /var : https://github.com/pfsense/pfsense/pull/1765
Maybe someone will think this is worthwhile for 2.3? -
/var is variable, volatile, and written a lot (especially /var/log, and /var/run but that's a different animal)
The data there may be nice to persist but it will write a LOT and that is what most people want to avoid with sensitive disks (flash media, especially)
Having separate options may be OK but I'm not sure it makes a ton of sense. There are few scenarios that would warrant using RAM for just one or the other instead of both or neither.
-
I am new to pfSense (been running about a month) and ntopng has already consumed more space in /var than can comfortably fit in a RAM disk.
As such, I find it hard to believe this is rare scenario.
I read somewhere that RRD uses /tmp for generating the graphs? If that is so, that one thing alone will be considerably quicker in RAM. Surely that is beneficial to everyone?
-
It's also data that gets written a lot. If you need something like ntopng to run, allocate more space to /var in RAM or deal with all the disk writes that come with putting /var and /tmp on the disk.
Having a split option wouldn't reduce disk writes in that case.
Either you care about all the disk writes or you don't. If you care, then put /var and /tmp in RAM, sized accordingly, or adjust your expectations about what packages will run on your system specifications.
If ntopng will be spamming the disk constantly, /tmp would be a drop in the bucket by comparison so the separate choice still makes little sense.
-
The motherboard I have maxes out at 4GB (I think technically it was 2GB but I found 4GB does work), it HAS 4GB, /var is already 1.7GB and I have no idea if that is going to continue to climb as its not clear how long it keeps its data. As such, having /var in RAM is probably impossible in my current configuration.
Its not about writes for me so much as its about speed.
When you are updating a stats file every couple of seconds and its constantly being read back also every couple of second, sometimes you will end up reading the file just as its being written. Even saving to a temporary file then moving it to the final filename once completed written, doesn't seem to avoid the file sometimes failing to load. My guess, some sort of delay in changing the file system pointer.
Write that file to a ram disk instead and it never fails to read, as the operations are near instant.
Now perhaps the way I am doing this is less than ideal, but its always worked perfectly on DD-WRT, OpenWRT or any normal Linux distro, as they always put /tmp in RAM these days. So I find it puzzling why pfSense does this differently.
As it stands, putting it in /var/run seems to be fine so a fix is not urgent. But I'm still confused at the reasoning.
-
Now perhaps the way I am doing this is less than ideal, but its always worked perfectly on DD-WRT, OpenWRT or any normal Linux distro, as they ALWAYS put /tmp in RAM these days. So I find it puzzling why pfSense do this differently.
Not so puzzling at all. The purpose for ram disk in pfSense was never about performance/speed. It was always about SSD / CF friendliness. That's the why.
The real question is whether or not splitting the option by /tmp and /var.
Generally I like more granularity in options. The finer the control the better.
-
That is clearly apparent. It just surprised me that they wouldn't offer that granularity as standard even if they weren't sure anyone actually needed it. Like you said, the finer control the better.
Perhaps Smoothwall would be more fitting to my requirements (it seems to have a lot more user friendly addons), but I'm not about to switch without giving pfSense a chance. The performance of my router did seem to improve compared to the OpenWRT build it was running before.
-
I'm not opposed to having a granular option there, the problem is that more often than not people will want both and may miss setting one or the other. Splitting it into two checkboxes makes new problems while "solving" one that would rarely be hit. It makes it more difficult for most users while benefiting relatively few.
It's a bit more complicated to code up but it may be better to have a drop-down that has options such as:
- /var and /tmp on disk
- /var and /tmp in RAM
- /var in RAM, /tmp on disk
- /var on disk, /tmp in RAM
With appropriate upgrade code to migrate from the old setting.
