RAMdisk or not?

ViciousXUSMC

@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.

stephenw10

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...

provels

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).

stephenw10

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.

provels

@stephenw10 Don't think so.
I just changed to ramdisks, rebooted, directories empty (expected).
Ran ~~update~~ reload/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.

stephenw10

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

jrey

@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.

jrey

@stephenw10

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 minimal

Now 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 here

You 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.

provels

@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.

slu

@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-ssd

Also using Snort, but my system has enough RAM (16 GB) to have a large RAM disk...

jrey

@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"

juliaadams43462

This post is deleted!