RAMdisk or not?
-
I have installed a 256 GB SSD in my appliance, and moved the installation over to the SSD (previously was on the eMMC). Should I move the /var and /tmp folders to a RAMdisk instead of just using the SSD? I only have 4 GB of RAM, so wary of tying up too much space on a RAMdisk. Also, I did notice that in the Netgate docs say "Modern SSDs do not have disk write concerns as older drives once did" (from https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html) - the SSD is a brand new M.2 SSD, which I assume qualifies as "modern".
Any advice?
-
You don't need to because of write cycle concerns. Anything vaguely recent will take many years to get anywhere near the write life with normal use.
You might choose to to prevent filesystem damage if the firewall is installed somewhere power cannot be guaranteed. The RAM disks do not need to be very large for a basic install, I usually recommend double the default so 80MB and 120MB. If you have packages writing to /var or you have increased the log sizes significantly you would need more.Steve
-
@stephenw10
I use pfBlockerNG and Snort - I understand these may cause more writes to disk. Not sure if that would affect your opinion? -
@pfguy2018 Most modern ssds have a writes figure, running at the terabyte level.
Pfsense writes mostly logs.
Take a weeks logs size increase and do a division.
If that figure is less than 300 weeks (which is more than five years) then its worth considering.
Keeping a confirmation backup is always a necessity.
Hdds fail too, especially when hot. -
@pfguy2018 said in RAMdisk or not?:
@stephenw10
I use pfBlockerNG and Snort - I understand these may cause more writes to disk. Not sure if that would affect your opinion?I am the Snort and Suricata packages developer/maintainer. I do NOT recommend using a RAM Disk with either of the IDS packages! They need a lot of room for logging (can easily approach Gigabyte levels if you don't enable automatic log rotation and if you have a busy network with lots of rules triggering). They also need at least 256 MB of free space in
/tmpin order to successfully download and unpack the rules update archives. A lot of folks have tried RAM Disks with those packages and encountered problems with running out of space.In my view, with modern SSDs, there is no really good reason to use RAM Disks if your firewall is on a UPS with either the nut or apcupsd package installed to automatically shutdown the firewall when the UPS battery is nearing exhaustion.
-
@bmeeks
Thanks for this input. I would say that your answer pretty much clinches the decision! I will stick with the SSD for logging. -
@bmeeks I know this is old, and I am necro posting but what about someone with a build like mine that has 32GB of RAM and never even use close to half of it?
But I also run two half way decent SSD as the OS disk in Raid 1 so loss of a disk sucks but atleast is not catastrphic.
But unused RAM is waisted RAM I could easily give 16GB of RAM to the RAM disk.
-
Probably fine.
However consider that the percentage of all systems running ram disks is low. That means that any config combination that includes running in a ram disk is far less tested than without ram disks. So you are more likely to find bugs there. Of course finding bugs is helpful so...
-
I used to use the ramdisk, but I found it annoying to be forced to update pfB manually because the pfB list downloads were lost anytime I rebooted (especially as a VM running on a Windows host, hence the reboots).
-
Mmm, pretty sure that has been fixed in pfB. I run both and don't hit that. The only time we might expect that is the first boot after restoring a config.
-
@stephenw10 Don't think so.
I just changed to ramdisks, rebooted, directories empty (expected).
Ranupdatereload/all, populated the lists.
Rebooted again, empty again.
The ramdisk backup schedule backs up /var/log, but not/var/db.
Running 3.2.0_10 (release). Am I wrong? No big deal for me either way, my FW is so overpowered.
-
It should be backed up here as far as I can see:
https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-pfBlockerNG/files/usr/local/pkg/pfblockerng/pfblockerng.inc#L4696 -
@provels said in RAMdisk or not?:
I found it annoying to be forced to update pfB manually because the pfB list downloads were lost anytime I rebooted
Just for clarification, when you say rebuild are you talking the DNSBL after a reboot is showing it starts in a down state? effectively then saying that the list is out of sync?
or are you simply concerned that the files in the various sub directories are gone (even though they are not needed for a restart of the DNSBL or rules (alias) for that matter).Use ramdisk all the time -- (both on the test VM that reboots a lot, because I shut it down normally when I'm not testing something) and the production box, which almost never restarts.
Have not seen an issue with the DNSBL starting in a "down" state.
-
Correct -- but I think the fact the .orig files are not there after a reboot is perhaps provels concern ?
They don't need to be there for DNSBL or alias lists (rules) to restore -- they are all considered transitional files - only items saved are the "active / final" bits to bring it back up to the state it was in before being shutdown.
Take a running system (delete all the .orig files, for example) nothing bad happens. It certainly doesn't impact the running DNSBL or firewall rules that are currently running based on anything in those directories. Then the files just get replaced next time the cron process runs and updates.
Not broken, IMHO.
side effect of running ramdisks (maybe a slight impact when cron runs to obtain the updates) but it is likely going to do that anyway in most cases (even if the files are already there) impact is minimalNow if the DNSBL (for example is starting in a bad state (out of sync for example) and provels is having to rebuild because of that, it is a completely different issue,
but again it just seem that perhaps having no .orig files after a reboot, based on the screen capture, is the concern hereYou will notice in the code you reference that it backs up unbound and the alias "stuff" (that's all it needs to archive) (effectively the running state) the rest is temporary fluff.
I run ramdisk both on a VM test box restarts frequently
and on production NetGate box, never been an issue with "lost" lists (alias) or DNSBL after a reboot. -
@jrey @stephenw10
OK, I guess you're right. Here's some screenclips. I know I used to see a warning on the Dashboard widget on the DNSBL, and not that long ago. Why I went back to disk rather than RAM.
On reboot the files get cleared from directories below /var/db/pfblockerng.
Before:
After: (ignore Shallalist)
The only file I see related to pfB is this. Is this the aggregated list that pfB uses/backs up/restores at reboot to keep it working? (14K+ lines)
Can you tell me where these lists exist after reboot if they're not in the db directory?
Thanks, gang.
-
@pfguy2018 said in RAMdisk or not?:
pfBlockerNG
In this case, please have a look into my topic:
https://forum.netgate.com/topic/189820/how-do-i-find-out-what-write-continuously-on-my-pfsense-ssdAlso using Snort, but my system has enough RAM (16 GB) to have a large RAM disk...
-
@provels said in RAMdisk or not?:
Can you tell me where these lists exist after reboot if they're not in the db directory?
the DNSBL you've highlight are with unbound.
@jrey said in RAMdisk or not?:
it backs up unbound
that is what is "providing" the DNSBL function
-- pfB just aggregates sources of data to build lists(alias) then used by unbound or rules. The data pfB uses is just the "step" between in that process of getting from source and using in DNSBL/firewall.
Source (Download) -> Originals (raw as provided by source) -> (Process to) (Deny, Match, Native, Permit etc) -> (provide to) DNSBL(unbound) OR (alias firewall)
(process to) = options like de-duplication, CIDR Aggregation etc -- not all options you've selected apply to all Originals. (check the info blocks, usually provided with each option to determine what happens for a given option)
so for example in the IP settings De-Duplication -- "Only used for IPv4 Deny Lists"
-
This post is deleted!
